Skip to Content

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

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. Gretchen Lindquist
    I agree completely, combining well documented rules for sensitive objects with a strong and well documented SU24 change management process can help you lock down a lot of potential security gaps and make your auditors/ controls compliance people happy. It never ceases to amaze me how many security folks don’t want to bother with doing SU24 changes, when it can save them a lot of time and grief in the long run. Good blog!

    Gretchen

    (0) 
    1. Julius von dem Bussche Post author
      Thanks Gretchen.
      Although it is an easy security gain, it can be very challenging to get the developers (SU24), the security folks (PFCG) and the role owners (the choice of transactions, and therefore the business process design!) together at the same table and using the same concept.
      I hope my blog will create more awareness for this… 🙂
      Cheers,
      Julius
      (0) 
      1. vinod doshi
        Hi,

        Might be a silly question, but plz bear with it.
        We have created some Z auth objects for Z t.codes & for some standard t.codes (in Exits & BADI).
        These objects are not listed in Su24 under the respective t.code.
        Please let me know what i am missing.
        What are the settings i need to do, to make those objects listed in SU24.

        regards,
        Vinod

        (0) 
          1. Julius von dem Bussche Post author
            By the sound of it you have not performed the installation instructions (in transaction SU25).

            Please ask your question in the SDN Security Forum (#208) and we can take a closer look at it…

            Cheers,
            Julius

            (0) 
  2. Otto Gold
    One can understand how this works, what one can spare and how one can build the roles the sustainable way… but I am very much interested how can I use SU24 for development:))
    Otto
    (0) 
    1. Julius von dem Bussche Post author
      Ideally it is the developer who maintains SU24 in customer systems for their developments, to indicate the authorization capabilities of the application and propose standard instances of auth objects consistently for the transactions which start these applications.

      So yes, please feel free to use it as a developer – it is “best practice” 😉

      Cheers and thanks for taking the time to read these old blogs of mine,
      Julius
      Julius

      (0) 
  3. Bridget Worth

    This may be some years old now but it’s still valid. There are many SAP systems out there that were set up in a rush by the Basis team with no Functional support and no knowledge of what a mess they were creating by not understanding the power of the SU24 default values.

    Thank You again !

    (0) 

Leave a Reply