Safe Protection of file access by all means

[Former Member]

Hello,

we currently in an implementation project we we get delivered sensitive denormalised data from special ledger.

Denormalised means in this case that we post transaction data and master data attributes in one file.

This is done due to technical reasons. For example if you have 1 million transaction data and 1 million master data

we speak about one trillion reads, which will be tear down performance in any case.

On development and test system we are currenlty in middle to get an anonymizatin solution on board.

For produtive enviroment we have to access the files via ABAP in order to validate them.

In SU21 (Overview authorisation objects) I found the authorisation object S_DATASET (see attachment)

which seem on a first sight suitable, but it the authorisation object have to by a ABAP programm over the function module AUTHORITY_CHECK_DATASET, which means every developer can develop an ABAP programm without the function module by accident or without. In both cases it means unlimeted access the files.

I'm looking for a more kernel based authorisation for file access.

Additionally it should be common sense to restrict to transactin AL11.

+ How can we protect the files in our productive enviroment by all means?

+ Are other threats beside ABAP programms for the files in our scenario?

We are on BW 7.0 SP23 / Basis 7.00 SP21 and ABAP 7.00 SP21. We are running on OS SunOS.

Regards & Thanks,

Guido Brune

Documentation on S_DATASET:

Definition

Authorizations for accessing files from ABAP/4 programs.

You use this object to assign authorizations for accessing operating system files (with the ABAP/4 key word OPEN DATASET, READ DATASET, TRANSFER and DELETE). This key word can also be used to assign the authorization for using operating system commands as a file filter.

In ABAP/4 programs, you perform the authorization check with the function module AUTHORITY_CHECK_DATASET.

Defined fields

The object consists of the following fields:

ABAP/4 program name: Name of the ABAP/4 program that contains the access. You can restrict the file access to a few known access programs.

Activity: Possible values:

33: Normal file read

34: Normal file write or deletion

A6: Read file with filter (operating system command)

A7: Write to a file with filter (operating system command)

File name: Name of the operating system file. Here, you can restrict the accessible files.

[jurjen_heeck]

> but it the authorisation object have to by a ABAP programm over the function module AUTHORITY_CHECK_DATASET, which means every developer can develop an ABAP programm without the function module

I would say that this is exactly why you test programs before they're used in production. There is a limit of what human behaviour you can catch with general measures and I think you have reached it.

To me your question reads like: "If the carpenter forgets to build locks on my doors, how can I secure my house?" and the answer is: "check the carpenters' work and do not accept it until the locks are properly installed."

So your answer lies in test scripts which include thorough authorization testing for all software interacting with the o.s. and file system.

[Former Member]

This is a special case. The authorization-checks on S_DATASET are automatic and build into the ABAP program language itself and not optional for the application code of the developer.

You cannot debug them nor turn them off... that is why it makes sense to check authorization using the function module before the program performs the dataset operation, as the check is going to happen anyway.

Actually, it does exactly that which you claim it is not

Cheers,

Julius

[jurjen_heeck]

> This is a special case. The authorization-checks on S_DATASET are automatic and build into the ABAP program language itself and not optional for the application code of the developer.

Didn't know that one. I say: "STICKY!"

[Former Member]

Hello,

thanks for prompt answers!

For sure we will test our development, but in this case the data could be value for competitors of our customer.

To write a programm which access the file is done in less that an hour by developer. It is about a 50 column programm.

The program can write after BC400.

Fortunately only limited persons get access to production.

To make it clear I'm not the person who distrust persons as initial attitude, but you never know ;-).

Julius,

when I found the S_DATASET I was happy, because I thought I found was I was looking for for. The I read the documentation

of the authorisation object which has nothing about the kernel implementation.

Menwhile I check the ABAP help on dataset which says the following:

Access can be permitted on three levels

1. Operation system check

2. Programm-independent check of access authorisation via table SPTH which can be access by SM30

3. in-built authorisation on kernel level via S_DATASET which is implict mentioned in ABAP help

The function module AUTHORITY_CHECK_DATASET can be executed in order verity authorisation before

the real file operation. The authorisation field FILENAME is only 60 characters long.

What will be done in scenario where you have longer filename as 60 charaters?

For me three level appoarch does make things more complicated in a possible sensitive area.

Thanks & Regards,

Guido Brune

[Former Member]

Hi,

Table SPTH and Auth object S_PATH ( Independent of ABAP Program) might help you. Please go through the below link -

[http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3d69358411d1829f0000e829fbfe/content.htm]

[Former Member]

Using the hook is very tricky and if you use the search you will find some details on this in the forum (more than just random links as answers...).

An easier solution is to transfer the path with the file name (or at least the prefix) from the input or accessible import parameters to configuration beyond the boundary of the users' influence and then control it via the program context, which is a field of S_DATASET you can specify for the users. SU24 will be your friend here. It is a hard day's work but it works well if your developers are co-operative. Customizing can be set or transported independently of programs, so they should like it.

Avoid generic transactions as much as you can and if you follow the route of protecting the variants then mark my words that it will return to bite those who have to maintain this in future, as you need to use S_PROGRAM and code a sy-batch check into each of them.

I cannot remember having ever seen a file with a name longer than 60 characters, but it will no doubt have been truncated so anything longer is a wildcard. I assume that was just a theoretical question?

> The program can write after BC400.

There are also otherways to access the OS from ABAP, but S_DATASET and S_LOG_COM are the main ones.

If some BC400 coder gets their arbitrary code into your system and runs it then your security is toasted anyway. You need to use authorizations for this and change controls.

Cheers,

Julius

[Former Member]

The difference between using S_DATASET and SPTH table/S_PATH auth object is that S_PATH auth object is independent of ABAP Program used to access files. So you do not have to worry about the ABAP program which is trying to change a file in that specfic path.

[Former Member]

Yep that is true, and it does that by grouping them. S_PROGRAM also groups programs (in the beginning... until you have to administrate roles for them).

What happens when the program lets the user define the directory path for the inbound file, and another lets the user define the directory path for reading the dataset?

S_PATH will not help you there. The program context of secure coding with input validation will...

Cheers,

Julius

[Former Member]

I think securiing the file path using SPTH table and S_PATH authorization object still make sense as an additional level of security check. Not sure if I am complicating things but seems to me these basic steps needs to be taken care of -

1. OP should find the file path where sensitive data would reside ..for example say /tmp/sensitive_files

2. Update table SPTH with this path and SAVEFLAG as X and FSBRGRU as the authorization group named for these files.

3. Make sure t-codes that can update tables are restriced in Production such as SM30 / SE16 / SE17 so that nobody can

change this table. Again restricting S_TABU_DIS as well.

4. Controlling the programs that have ability to read and write to these sensitive files by using S_DATASET object by updating the

field for program name and file path for the sensitive files in this object.

5. Giving access to S_PATH and S_DATASET to users who really need to have access to this file path and programs that can access these files.

S_PATH will help because suppose some previous security administrator has given S_DATASET object in any role with Wild card access but without S_PATH they still will not be able to update the file.

> "What happens when the program lets the user define the directory path for the inbound file, and another lets the user define the directory path for reading the dataset?"

>

The following setting restrict ABAP programs to access any files on the application server apart from those in the path u2018(/tmpu2019).

-

PATH SAVEFLAG FS_NOREAD FS_NOWRITE FSBRGRU

* BLANK X X BLANK

/tmp BLANK BLANK BLANK BLANK

So technically you can control paths which can be accessed by the ABAP programs.

Edited by: Nishant Sourabh on Sep 13, 2010 10:48 PM

Edited by: Nishant Sourabh on Sep 13, 2010 10:50 PM

[Former Member]

I agree that S_PATH is usefull to retro-fit selected protected paths from users with full access to S_DATASET. That is also realistic.

But much like the myriads of S_PROGRAM groups and implications of not assigning a group to be able to use "actions", it is not scalable for granular control via roles.

For example, you cannot use it for org. level values.

You can however do this very easily in ABAP programs with config and file suffixes based on authorizations.

The biggest problem are the generic includes. It was the same with S_TCODE way back as well.

The program name and secure coding parameters is a more sustainable option in my opinion. But for that you need coding standards, co-operative developers and competent code reviews.

And you need SU24 to have "entry points"

But I agree, S_PATH does work as a blunt tool.

Cheers,

Julius

Edited by: Julius Bussche on Sep 13, 2010 11:32 PM

[mvoros]

Hi,

just to add my 2 cents. Take a look at OSS note 177702 - Files: Authorization objects S_PATH & S_DATASET. It nicely summarizes all info about these two authorization objects. It also confirms what Julius wrote. It cuts extra characters if field name is longer that 40 characters.

+ Are other threats beside ABAP programms for the files in our scenario?

Yes, don't forget external OS commands (transactions SM49 and SM69). For example by default there is a record for Unix command cat.

If I understand you your situation correctly then you have two customers on your production system and you want to prevent customer from writing a rogue program which could steal data of other customer. Probably the only feasible solution is to add security code review before releasing anything to production. You can try to automate this with help of code inspector (transaction SCI). You can define your own profiles. Especially, check section Search Functs.

Cheers

[Former Member]

Hello,

no there are not two customers on the system,

but our client etasblish data protection on board level due to some events in the past.

Therefore we have to our best protect his data assects.

The length restriction of the authorisation field "FILENAME" is in my opionion an issue.

In another area of this application we have set the follwoing directory / file name structure:

/daten/ -> 6 charates long

<Project name>/ -> 20 charaters long

<type of processing stage like Archiv, Eingang and Verarbeitung>/ -> max 13 charactes long

<filename with the following syntax <organistaion unit (4)>_<monat (6)>_<type of data (20)_<process stage (2)_<timestamp (14) (optional).csv

This sum up to approx. 90 charaters for full specified file name. In implementation I was not aware of the limitation of the authorisation object S_DATASET. We can shorten the file name, but this the second best apporach.

I personally think SAP need to rethink the authorisation concept. In BW they overcome the limitation of authroisation objects.

Does anyone known if there is a new appoarch on authorisation in busines-by-design?

Regards & Thanks,

Guido Brune

[Former Member]

> In implementation I was not aware of the limitation of the authorisation object S_DATASET.

I hope you first agree that this was your mistake for concocting a concept which looks nice on paper but is unimplementable in the system?

Particularly, you seem not to have noticed that the field in S_DATASET is the file name ...

Via S_PATH you can extend the file path to 86 characters but then only control via the group of the path and not the exact path itself (see discussions above about directory traversal attacks).

But still, if someone gets their code into your system then they will access the operating system regardless of your S_DATASET and S_LOG_COM restrictions.

For example, is the C-call to 'SYSTEM' permitted on the server? Have you restricted your ACL list of hosts allowed to start external programs at the SMGW gateway? Etc...

If your customer wants to achieve "by all means" security then it is not an easy task by any means and requires considerable experience to make quick but sustainable wins with lower effort. You at least have to have read the documentation and latest OSS notes on the topics...

Cheers,

Julius

[Former Member]

Hi Guido,

if you do not trust your developers, then the only way to protect your files in this case is indeed a code inspection.

You can do this manually. But this can become costly if you need to perform inspections repeatedly.

You can also do this with a tool. You can define test cases for Code Inspector (shipped with the SAP release) as Martin already pointed out. You can also use CodeProfiler (not shipped with the SAP release), which already comes with test cases for OS command execution and file access. SAP also uses CodeProfiler for ABAP security QA.

By Design uses a completely different authorization concept. But if someone can code ABAP, this won't help either.

Regards,

Andreas

[Former Member]

Hello,

currently I'm reading the book "Sichere ABAP-Programmierung" from SAP Press. Only page 35,"but" very promising.

In June 2011 I attend on a ByD session. In ByD Development Envrioment you write ABAP Script (C# derivat), which then translated into ABAP code. Therefore SAP can control security relevant in native ABAP code. On user level there should be still a security/authorisation check.

All the best,

Guido

[former_member102735]

Hi Guido,

I'd like to sum this up as most of the information has already been mentioned:

- OPEN DATASET performs an implicit auth. check

- Use S_PATH and S_DATASET

- Don't forget to maintain table SPTH

- Check and install [https://service.sap.com/sap/support/notes/1497003] (SAP Note 14970003) and their updates. Also check the attachments, there is a lot of documentation included. This will install FM FILE_VALIDATE_NAME

- Prior to calling OPEN DATASET, call FM FILE_VALIDATE_NAME and handle the exceptions

See also [http://help.sap.com/saphelp_nw73/helpdata/en/4c/b27910d9173d8ce10000000a42189e/frameset.htm]

Best regards,

Frederik