How safe is S_PROGRAM?

[ThomasZloch]

Dear all,

I need to restrict user access to certain technical programs where standard authorization objects are not applicable. Assigning authorization groups in the program attributes via RSCSAUTH combined with roles featuring the necessary S_PROGRAM authorization seems to be the way to go. However I'm wondering whether this is a 100% waterproof protection, considering that no further AUTHORITY-CHECK statements appear in the code and all roles are carefully constructed to not include sloppy asterisk logic.

I have tested the following program execution methods and found the appropriate traces in ST01:

- SA38, SE38, SC38, SE80, SUB%

- transaction and area menu

- SUBMIT from other programs

- .sap shortcut on desktop

- job scheduling

Is there more ways of executing a program?

Have you heard of any loopholes in the S_PROGRAM protection, especially regarding RFC calls?

Many thanks

Thomas

[Former Member]

Note that there is a slight difference between the the checks in the workbench transactions (SE38 & Co.) and the many generic report start utilities (SA38 & Co.).

For the latter (SA38, etc) S_PROGRAM p_action VARIANT is sufficient to submit the program via it's selection screen as well.

For the former (SE38, etc) you can also activate activity 16 for single testing (thereby permitting source code display without the risk of execution).

A work-around known to me are external form routines. Search the Coffee Corner for "Nokherberg Maibok"...

Cheers,

Julius

[ThomasZloch]

Thanks for your reply, Julius.

> A work-around known to me are external form routines.

As in "PERFORM subr IN PROGRAM prog"? Good point. I just tested, auth group of "prog" is not being checked. I could build in a check on SY-CPROG in critical subroutines and stop if not equal SY-REPID.

> Search the Coffee Corner for "Nokherberg Maibok"...

0 results ;(

Thomas

[Former Member]

Sorry that should have been [nockherberg|https://forums.sdn.sap.com/search.jspa?threadID=&q=nockherberg&objID=f255&dateRange=all&numResults=15&rankBy=10001] ...

> As in "PERFORM subr IN PROGRAM prog"? Good point. I just tested, auth group of "prog" is not being checked. I could build in a check on SY-CPROG in critical subroutines and stop if not equal SY-REPID.

Of course you might want to modularize that, and also create trusted pairs of sy-cprog : sy-repid combinations.

Another (possibly better) way of doing it is to call FM AUTHORITY_CHECK_TCODE at initialization of the program. That way you could reuse the forms or the whole program, but only from a defined set of trusted transaction contexts. This would however be tricky for job-steps though, so you might want to include a sy-batch exception as well before calling the FM.

Cheers,

Julius

[ThomasZloch]

> Sorry that should have been [nockherberg|https://forums.sdn.sap.com/search.jspa?threadID=&q=nockherberg&objID=f255&dateRange=all&numResults=15&rankBy=10001] ...

Lol. I was involved in that thread, but it's been one year and I couldn't recall.

> Another (possibly better) way of doing it is to call FM AUTHORITY_CHECK_TCODE at initialization of the program.

Not all of those programs will have a Tcode assigned, but I could put an AUTHORITY-CHECK on object S_PROGRAM there, checking the auth group as found in TRDIR-SECU. This would duplicate the built-in check, but I could be certain that there is no way to start the program in whatever way without that check.

Thomas

[Former Member]

Of course the security puritan in me still thinks that the correct checks in the forms (depending on what that form performs) is the better option. That way, then can be used and work-around like above will experience those same checks regardless of the caller.

Perhaps the hard S_PROGRAM check is an over-kill, in addition to being a rather blunt tool...

If I may ask, is this a retro-fit of security to custom programs in which security was not considered initially? Although easy to add the security at first, the other side of the coin of using S_PROGRAM only is that the authorization complexity will increase, together with the number of roles required, depending on the number of programs and diversity of what they do. It is not scalable in the long run, IMO.

Cheers,

Julius

[ThomasZloch]

> Of course the security puritan in me still thinks that the correct checks in the forms (depending on what that form performs) is the better option. That way, then can be used and work-around like above will experience those same checks regardless of the caller.

I'll think about that in more detail, thanks for the impetus.

> Perhaps the hard S_PROGRAM check is an over-kill, in addition to being a rather blunt tool...

I would like to avoid it if possible.

> If I may ask, is this a retro-fit of security to custom programs in which security was not considered initially?

Exactly. Internal revision and auditors are on the horizon, and I'll have to come up with something that pleases them, trying to stick to SAP standard if at all possible. This is for programs like "delete file on app server", "mass-update of original system in TADIR", various interfaces...

> Although easy to add the security at first, the other side of the coin of using S_PROGRAM only is that the authorization complexity will increase, together with the number of roles required, depending on the number of programs and diversity of what they do. It is not scalable in the long run, IMO.

I have identified four different values for P_GROUP that will be needed. My client is using S_PROGRAM already, but over the years roles and actual program auth groups went out of sync, so the whole thing needs a cleanup anyway. Afterwards there will be less complexity than now.

What I'm looking for is basically a confirmation that S_PROGRAM alone provides sufficient protection if implemented properly, so that only users with an appropriate role assignment can execute a certain program.

Cheers

Thomas

[Former Member]

> What I'm looking for is basically a confirmation that S_PROGRAM alone provides sufficient protection if implemented properly, so that only users with an appropriate role assignment can execute a certain program.

IMO, yes. By the description of the programs you mentioned, a blunt tool should be heavy enough as well for them. Besides, an external perform would typically require that the person can get their own calling program into the system - in which case they have won anyway. Via RFC there might be more ways.

But on it's own, S_PROGRAM is not enough to be a considered "a concept" and as you already experienced, it grows out of sync / overview / temptation to pop a * into an auth field / etc over time if too complex. For example there are other standard ways to delete a file from the app server. The correct object to use is S_DATASET, which will not care where the caller is coming from. You cannot even debug it... For SM37 it is S_LOG_COM.

Another suggestion which I have is to check the client settings for the program to be used? Or just delete them in Production if they should not have found their way there in the first place.

I have done a few such clean-ups as well, and there are a number of "gotchas" - S_PROGRAM for many programs is one of them (even although it does work).

Cheers,

Julius

ps: In an ideal world, there would be a BAPI for everything

Edited by: Julius Bussche on Jan 22, 2009 3:20 PM

"ps" added.

[ThomasZloch]

Thanks very much for your insights. That's gonna be another beer on the next occasion

I will leave the thread open for the moment, should there be more comments.

Cheers

Thomas

[Former Member]

> That's gonna be another beer on the next occasion

Sounds good.

> I will leave the thread open for the moment, should there be more comments.

Yes, please do. There are a few gurus who pop by on Friday afternoons sometimes

Cheers,

Julius

[Former Member]

Another thing which occurred to me is report type transactions which submit type 1 (executable) reports might not be the only ones in the system.

You cannot use S_PROGRAM to protect module pools, interface pools, transformations, etc which are invoked by dialog or OO transactions, or other callers (including the menus of report transactions, and RFCs) which at first might appear to be harmless.

For those you will need to secure the transaction or protect the RFCs, but if you use them then there is no way around coding correct authority-checks into the programs themselves.

See also

Cheers,

Julius

[ThomasZloch]

Thanks for pointing this out, fortunately the programs in question are all type 1 reports.

Cheers

Thomas

[Former Member]

I know this is a bit out of date, but did you consider a user running LSMW that executes one of your programs while using another user's ID?

[ThomasZloch]

Still here, still here...

I think you need authorization S_BTCH_NAM in order to schedule background jobs (like a BI session running in background) under a different user name than your own, so that's independent of S_PROGRAM.

If you start BI sessions online, they will run under your own user ID.

Thomas