Users Access to SE38

[Former Member]

Greetings everyone,

As far as I know users with access to SE38 can run any ABAP program that is not assigned to an authorization group (and does not have authorization check in the code i guess). My understanding is that this is a security hole is SAP systems which has always been highlighted in SAP security literature.

I was raising this issue to our basis administrator and we ran a small test as follows:

We created a test user and gave him only the following access:

S_TCODE

SE38

S_Program

activity: Submit

Auth: *

When we tried to execute programs that has no authorization group assigned with this user we were NOT able to, we got a message saying "You have no authorization to execute the report SE80/SE38"

How can this be the case? What are the authorizations necessary to be able to run programs not assigned to authorization groups through SE38?

Your prompt response is highly appreciated.

Many thanks in advance

Issam

[Former Member]

I would advise not to give end user SE38.. instead give SA38, if you don't want to create a transaction for the report..

the best way to ensure user can't access the report is to enforce some security checks in the code itself.

[fredrik_borlie]

You should never give access to generic transactions like SE38/SE80.

Instead. Create a new Z-transaction using SE93 for the report and assign the report instead.

Then you assign the new Z-transaction to your role and you do not risk the SE38-issues with auditors etc.

/fredrik

[Former Member]

From your post it looks as though you don't need the standard "don't give SE38" replies.

Can you give some example programs? My guess is that the programs you are trying to run have a default auth check on another object that is carried out right at the beginning of the program execution.

An ST01 trace would prove or disprove this.

[Former Member]

Hi,

The SUBMIT: Start the program auth allows access only for the reports having assgnment to auth groups. When ever you try to access a report with no auth group assigned it will throw the same error.

[Former Member]

Amit Singh Thakur wrote:
Hi,
The SUBMIT: Start the program auth allows access only for the reports having assgnment to auth groups. When ever you try to access a report with no auth group assigned it will throw the same error. 

This is not correct. If no program group is maintained, the S_PROGRAM check does not take place.

The problem here is that SE38 itself also checks S_DEVELOP actvt '03' for object type 'PROG' at the start of the transaction (see SE93) and this is not in the manually built role. Add SE38 to the menu, and it would pull it's proposals and then work (and also check actvt '16' if the SP level is high enough...).

Cheers,

Julius

[wilder_latino]

Hi,

as Julius mention this is an incorrect misunderstanding. It is best to put an auth group to a program.

Here is some documentation that should assist you. The reason why SE38 or SA38 is a not recommended in a Production environment is that users could execute programs that they should not be executing. An example is a user does not have access to the transaction code but can easily find the underlying program of the transaction code and than execute the program. It is very difficult to restrict the access via SA38 or SE38.

When a program does not have an auth group you only need S_DEVELOP with proper values. When you have an auth group assigned to the program than you need a combination of both authorization objects with proper value.

Keep in mind that many programs share the same auth group so you think you are granting them access to one program but you could be providing them multiple programs.

What I normally do to protect the system is I add this type of access via a FireFighter ID and lock SE38/SA38 via SM01. Also have a strict process in place.

The problem you will encounter is that functional users will insist that they must have SE38 or SA38 because it is more convenient for them and they will inform you that they don't know all the programs they need. Sometimes many organizations rather have convenient over Security. Your auditors should be able to back you up in why having such access is a risk.

One experience I had is a user deleted the entire HR Org Structure by executing a program. Another one is that a user was able to execute HR reports via SE38 even when the user had no HR transaction code.

I have to be honest though it will be very difficult to win this battle when upper managament do not have Security as their priority.

Authorization Group

Authorization group to which the program is assigned.

The assignment of a program to an authorization group plays a role when the
system checks whether the user is authorized to:

• Execute a program

--> Authorization object S_PROGRAM

• Edit a program (-Include) in the ABAP Workbench

--> Authorization object S_DEVELOP

Programs that are not assigned to an authorization group are not protected
against display and execution.
Security-related programs should, therefore,
always be assigned to an authorization group.

Report RSCSAUTH can also be used to assign programs to authorization groups.
This report is documented in detail.