No control over workbench tcode start

[Former Member]

Hello All,

Just want to confirm something.. there is no way of restricting people from starting workbench tcodes (SE37, SE38, SE80, SE93 etc). That is, everyone with access to the system can start the workbench tcodes even without S_TCODE access to them.

1. Menu: System->Status

2. Double-click on the program.

3. Hit shift-F5, and then navigate to whatever object you like.

You still need the S_DEVELOP and S_PROGRAM and soforth to progress further than the tcode start, but we've lost a layer of control here in that there is no S_TCODE restriction.

Am I correct in this thinking?

[Former Member]

Correct.

But the good news is that you can use s_develop to restrict the access. There are also other navigation paths available via other s_develop object types (try F1 -> s_develop 03 TABT) and the user could access almost any transaction code or other object.

See also OSS note 587410 -> Activate activity 16 for s_develop object type FUGR.

There is also a note about s_develop actvt 16 PROG (testing reports from the workbench).

There are also some notes about single step and update debugging (s_develop 03 DEBUG).

[christian_wippermann]

Dear Justin,

You are correct in your reasoning. However, as you also mention you do need S_DEVELOP, which your business users should not have. Additionally, you can restrict the possibilities to execute function modules using S_DEVELOP: <a href="https://service.sap.com/sap/support/notes/587410">SAP Note 587410</a>.

If this is not sufficient for you, please sent a development request to security@sap.com.

Best regards,

Christian

[Former Member]

Hi Justin,

Note that s_program is optional:

FORM CHECK_ABAPSUBMIT_AUTH USING PROGNAME VARIANT SSET SECU.

* Start nur über Variante? --------------------------------------------
  IF SSET >< SPACE.
    IF VARIANT = SPACE.
      MESSAGE E623(DB) WITH PROGNAME RAISING JUST_VIA_VARIANT.
    ENDIF.
  ENDIF.

* Ausführungsberechtigung ---------------------------------------------
  IF SECU >< SPACE.
    AUTHORITY-CHECK OBJECT 'S_PROGRAM'
                    ID     'P_GROUP'  FIELD SECU
                    ID     'P_ACTION' FIELD 'SUBMIT'.
*   keine Ausführungsberechtigung für Gruppe
    IF SY-SUBRC NE 0.
*     mit Berechtigung für Variantenpflege auch Ausführen erlaubt
      AUTHORITY-CHECK OBJECT 'S_PROGRAM'
                      ID     'P_GROUP'  FIELD SECU
                      ID     'P_ACTION' FIELD 'VARIANT'.
      IF SY-SUBRC >< 0.
        MESSAGE E092 WITH SECU RAISING NO_SUBMIT_AUTH.
      ENDIF.
    ENDIF.
  ENDIF.

ENDFORM.

So if the authorization group (TRDIR field SECU) is found empty, SAP does not check a "dummy" or a " " or "" but rather bypasses the s_program check entirely, unless the program is flagged to be submitted only with a variant, in which case the user would need to go to SA38, SE39, SC38 etc to add a variant.

There was an interesting contribution a few months ago on using the variant check to prevent an F8 user from running the unprotected report, but still permitting a SUBMIT statement to execute any unprotected report during processing. There was also a report you could put an authorization group on to prevent someone from changing the variant. I will see whether I can find it again.

[Former Member]

Duplicate post deleted.

Message was edited by: jbussche

[Former Member]

Another try...

"There is a way to handle this. In the latest versions (including 4.6c if you have 
installed the correct OSS notes) you can put an authorization group on every program, 
say ALL, except those that you need to explicitly protect with something stronger. 
Then give everyone S_PROGRAM with action VARIANT and authorization group ALL. 
They will not be able to submit these programs from any code editing window no matter 
how they get there because all of the editors require S_PROGRAM with SUBMIT authority 
(which you won't give). Everyone will be able execute the programs with ALL authorization 
group if they are assigned to a transaction code or to a menu tree or called from within 
another program. They will never notice because VARIANT authority is enough to submit a 
attached to transactions or called from programs etc. 

Managing the process of assigning an authorization group to every program has a few 
challenges but they are manageable."

[christian_wippermann]

Hi,

I had a look into an ERP2005 system with Industry Solution extensions. The number of programs is 2.539.398 (count the lines in TRDIR). The number of programs that is assigned to an authorization group is 7.336 (Non empty field SECU in TRDIR).

"Managing the process of assigning an authorization group to every program has a few challenges but they are manageable."

Who can report to successfuly control program execution using S_PROGRAM and program authorization groups? How did you identify all risky programs and assigned them to a proper authorization group?

Regards,

Christian

[Former Member]

Hi Christian,

This statement came from a consulting company. As I do not know them (other than hearing about this approach which is apparently theirs), I did not reference the source.

My understanding of their approach is that you do NOT have to identify risky programs (necessarily). What you do to the many type 1 programs which have an empty SECU field, is that you put an ALL group on them (except the few which you cannot) and give S_PROGRAM group ALL action VARIANT to all the users in the system (all of them).

The program will be unhindered if it is a report transaction (i.e. the user has the s_tcode), or unhindered if it is selected from a report tree (i.e. the report has been explicitly added to the report tree and the user has access to this menu), or unhindered if another program submits it during runtime (i.e. it is extremely difficult to know where a program could potentially be used from).

How ever, the user will be hindered if they F8 the report from the workbench, object navigator, SA38, Se38 etc etc...

I make no statement about the success of this approach.. but it is an interesting approach to the problem of the 1,517,967 unknowns in the system which I am looking at.

Kind regards,

Julius

[Former Member]

Dear Julius,

I just tested the authorization checks of S_PROGRAM when a protected program is called via a transaction.

On an ECC 5.0 system (6.40 Basis) I tried transaction BDMONIC starting report RBDMONIC which is assigned to authorization group S_ALE.

The authorization trace show a test against S_PROGRAM (P_GROUP=S_ALE;P_ACTION=SUBMIT) next to the TCODE check on BDMONIC.

Unfortunately I cannot check what happens if the test in S_PROGRAM / SUBMIT fails. Maybe the system then checks for S_PROGRAM/VARIANT and happily executes the report then.

Did anybody test this ?

Did I miss some "optional" OSS notes that would change the behavior ?

(Site Note: I noticed that report RSCSAUTH itself in ECC 5.0 / 6.40 is now assigned to an authorization group - at least something. But in earlier versions it wasn't !)

Regards,

Ralf

[Former Member]

Julius,

I can't see how that would work to be honest. ie, if all programs that currently have nothing in the SECU field are populated with ALL in the secu field, then everyone receives S_PROGRAM with SECU=ALL, then that would mean that everyone can execute all programs again in exactly the same way as if the SECU field was left blank.. even via SE38/SA38 etc.. wouldn't it??

The only way that I can see this thing working now is if all SECU=BLANK programs are initially assigned 'ZZZ' for example, and then we go through the process of testing each role to see whether or not the tcodes require S_PROGRAM access to the program. If they do, then move that program into a separate SECU and modify SU24 so that it brings in S_PROGRAM (if necessary). This shouldn't be too much of a problem if all tcodes in all roles are going to be tested anyway, such as during an implementation or redesign. It then means that we have potentially a million programs that are left in ZZZ and no one has access to run them.

[Former Member]

Hi,

Take a look at the above coding for the s_program check (it is from the program which manages the runtime of abaps). If the SUBMIT check fails, it alternately checks VARIANT. And these check are only performed at all if SECU >< space. If the check is satisfied by VARIANT, then it passes because the end result sy-subrc = 0, even although your trace is saying that sy-subrc >< 0 when no SUBMIT action is found. So what if sy-subrc is not 0 when the program does not react to it? This is a nice example of why you should be carefull of the results in the ST01 trace and even more so of the SU53 (last failed auth check).

I am not sure which OSS notes are being refered to. My tip would be those which relate to the s_program action BTCSUBMIT which could provide for some surprises when the abaps all have 'ALL' group and the s_program check is no longer surpressed. When an auth check is performed, the user needs to be able to logon (i.e. not locked, must exist and potentially the user which scheduled the step needs to have the authorizations too / still...)

This appraoch does add a layer of protection back again, but I do not lay my hand in the fire to say that it works in all cases (reports) in all releases, so please be carefull and test it well if you want to try it. There are some type 1 abaps you cannot put an auth group on -> e.g. those which are submitted BEFORE logon = SAPMSYST and potentially any other report run with a submit statement from a user exit in it. You also need to consider the change for ALL users in ALL clients in the system and if it is not possible to assign abap authorizations to a user, then you should not secure a report which it runs.

Side note: I did hear that there are some interface pools which could cause problems, but I have not encountered them nor tested any such solutions. RSCSAUTH checks SAP_ALL...

Kind regards,

Julius

[Former Member]

"<i>The only way that I can see this thing working now is if all SECU=BLANK programs are initially assigned 'ZZZ' for example, and then we go through the process of testing each role to see whether or not the tcodes require S_PROGRAM access to the program. If they do, then move that program into a separate SECU and modify SU24 so that it brings in S_PROGRAM (if necessary). This shouldn't be too much of a problem if all tcodes in all roles are going to be tested anyway, such as during an implementation or redesign. It then means that we have potentially a million programs that are left in ZZZ and no one has access to run them.</i>"

Definately do not do this. It will not work because the system uses many programs in many ways, even although the user only sees a tcode (or at most the main report).

[Former Member]

Dear Julius,

sorry - I did not check the coding (but actually expected somthing like that).

Nevertheless: The way I understood "the approach", it requires that S_PROGRAM/VARIANT is sufficient for starting reports via parameter transactions, report trees, ... but for the start of reports via SA38/SE38 you would need S_PROGRAM / SUBMIT.

Correct ?

Thanks and regards,

Ralf

[Former Member]

Correct.

PS: Keep an eye on ST22 when you go about doing this.