In part 1, Alex Ayers and Julius Bussche wrote about using transaction SU24 and how it documents and reproduces “authorization use cases” for specific entry points which are maintained via the role menu (transactions, RFC and services). Based on some feedback and subsequent discussions in the SDN Security Forum, I decided to give a more concrete example of such a “use case”; one which is not obvious to the naked eye...
In ABAP systems, access to operations on the file system of the application server are often performed using DATASET commands to create, read, transfer, delete, etc files from ABAP programs.
From the F1 key on ABAP statement DATASET.
Invisible (but documented) authority-checks.
Even if you do not check the authority of the user in your ABAP program (AUTHORITY-CHECK object ‘S_DATASET’), the authority-checks are still performed by the kernel anyway, and the program will dump if the user is not authorized (runtime error OPEN_DATASET_NO_AUTHORITY).
How to find and check the authority in ABAP.
Now obviously, if authority is going to be checked anyway beyond the ABAP program coding itself, then it makes sense to check that authority in the program before it dumps…
For this purpose, SAP provides function module AUTHORITY_CHECK_DATASET into which the calling parameters can be exported for the check on S_DATASET invoked by the subsequent commands. This gives the developer an opportunity to react to it first… In a development system, these field values can be found (if not known already) using the ST01 authorization trace on that application server, or single testing AUTHORITY_CHECK_DATASET using that the intended role.
Concentrate on the program and activity first.
The S_DATASET object (checked by the FM and the ABAP statement) will check the name of the program (field ‘PROGRAM’) from which the DATASET file activity (field ‘ACTVT’) is performed. So by restricting the program names in the user’s S_DATASET authority, the functional scope is restricted to only that which the application program was programmed to do. This is an easy and big security gain.
Of course, the program should ideally perform further application data related checks using the appropriate application authorization objects, as well as differentiating between the activities which the program is capable of.
Note that if the ‘PROGRAM’ parameter of the FM is initial, then FM will determine the name of the calling program itself. In fact, the “pattern painter” in the ABAP Editor will comment it by default. This is recommended for ease of reusability (to some extent 🙂
SU24 - Don’t reinvent the wheel each time.
The above described checks are subject to the authority of the user for S_DATASET authorization object. As the programs of many transactions can be expected to perform file system operations, transaction SU24 can be used to document the proposals for the activity (READ, OPEN, DELETE, etc) and program context (name) such that any subsequent use of the functionality (which will require appropriate authority) does not have to be re-traced, re-investigated, re-dumped, re-debugged... or just plain old *…
When adding the transaction etc to the menu tab of the role in PFCG, the system will then pull in the required S_DATASET object with the field values already populated as "standard" authorizations for that transaction.
“Hooking” the directory paths to protect groups of them.
Some programs might expose the application server path as an input parameter for a screen which the user can control. This is potentially subject to directory traversal attacks, particularly if the program does not make any subsequent application related authority-checks and/or depend on configuration (e.g. some RFC’s call themselves again using the application server specific configuration, such as the domain controller check in the TMS). Therefore the application developer should be carefull (as well as the role developer) which fields are passed through as input parameters without being “sanitized” first or checked for authority.
So what do you do if you have users who can influence the directory path or you want them to influence the directory path but restrict the input fields to exclude certain (groups of) directory paths?
Where are all these invoices coming from?
If function module AUTHORITY_CHECK_DATASET is used to check the authority of the user before the file operation is performed, then the possibility exists to activate an additional check on authorization object S_PATH for a so-called “path hook”. This is done by assigning authorization groups to specific directory paths as a protective mechanism, even if the user can influence the path input and attempt to read from or write to a directory of their choice. The platform specific paths can also be grouped together into authorization groups (see the documentation on S_PATH in transaction SU21).
Looping back to SU24 – a “my life would have been much easier” moment.
It is sometimes a tough call to write cool applications which are then subsequently also used in the manner were designed. Adding authority-checks is sometimes even counter-productive (it might seem…) as the added complexity will confuse the authorization administrators even more… and there are timelines and deadlines as well… the file system access for example is sometimes neglected in favour of (weaker) restricted transaction code entry points (the cool applications).
But with ~ 3 million programs in an ABAP system and an untold number of directory paths on the file systems, how could one (or a team of people) build sustainably secure roles without documenting which objects the transaction has the capability of using (check indicator only) and which proposals should always be reused (Check and Maintain indicator) from SU24?
Those timelines, deadlines, counter-productive tasks and cool (other) things to do remain after go-live as well, and chances are fairly good that someone working on some role will someday just pop a * into the fields of S_DATASET if they have no information to work with from SU24 when the intended use of the application was being developed.
A (bad) example, and potential consequence of not maintaining SU24:
Conclusion of Part 2.
Writing ABAP applications which use file system access can be made much easier (and secure) by calling FM AUTHORITY_CHECK_DATASET and maintaining transaction SU24 for the intended use-cases (particularly the program names, and grouping the paths if required), as the folks who build the roles do not need to reinvent the whole concept (and find all the detailed program, activity and path information) when working on roles for it. It will be proposed to them each time, so they have no excuse.
The responsibility here is primarily on the side of the developer, preferably working together with security.
PS: The authoritative SAP Note on these specific objects is 177702 - Files: Authorization objects S_PATH & S_DATASET
- SAP Managed Tags:
12 Comments
