Edit function removed from SE16N transaction, reports and interface FM

[Former Member]

For those of you who are interested, the edit function in transaction SE16N has been disabled and is also available via SNOTE - see [SAP Note 1420281|https://service.sap.com/sap/support/notes/1420281]

I personally still recommend a tight control on DEBUG authority, as the edit function in SE16N was actually just a user friendly extention of the debugger's capabilities - sufficiently so that even most auditors could work it out...

You can read more on the background here --> [TIP: Editing any table in SAP!!!|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16008] [original link is broken] [original link is broken] [original link is broken];

What do you security professionals think of this?

Will the auditors now backoff on this "illegal" application transaction (not basis!) and unlock it in SM01?

Is debug okay now because "a bug" in SE16N is fixed?

(ha ha ha...

This will be interesting to watch.

Cheers,

Julius

[Former Member]

I give it 3 years before work programs are updated...

[Former Member]

>

> I give it 3 years before work programs are updated...

This.

I have no idea why I find that remark funny, if you look closely at it - it is in fact sad ... but so true.

Maybe one day we get a stable version of MIGO, also (hahaha ... ha).

Thanks for sharing that note, Julius - I'll implement it next week and come back with the results.

O.k. now I am really out of here.

Nice weekend, all.

[Former Member]

> Maybe one day we get a stable version of MIGO, also (hahaha ... ha).

I like your optimism

That has been pencilled in for ECC20

[Private_Member_119218]

Interesting. The notes is valid for my release but I was unable to reproduce the described functionality.

Do I understand this [blog post|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16302] [original link is broken] [original link is broken] [original link is broken]; correctly in that a user needs S_DEVELOP object with OBJTYPE = DEBUG and ACTVT = 01, 02, 03? As in, must have 01 AND 02 AND 03, and any other combination will not work?

Cheers!

[Former Member]

> The notes is valid for my release but I was unable to reproduce the described functionality.

Which "release" is that? Take note that SE16N and it's functionality is a SAP_APPL component, not SAP_BASIS!

> As in, must have 01 AND 02 AND 03, and any other combination will not work?

Yep, all three are checked. The interface FM only checked '03' for a while, but to subsequently also save with the edit function active makes those same 01 AND 02 AND 03 checks again.

Cheers,

Julius

[Private_Member_119218]

>

> > The notes is valid for my release but I was unable to reproduce the described functionality.
> Which "release" is that? Take note that SE16N and it's functionality is a SAP_APPL component, not SAP_BASIS!

604, sp03.

>

> > As in, must have 01 AND 02 AND 03, and any other combination will not work?
> Yep, all three are checked. The interface FM only checked '03' for a while, but to subsequently also save with the edit function active makes those same 01 AND 02 AND 03 checks again.
> 
> Cheers,
> Julius

And disregard my previous post. I misunderstood the instruction for activating this. I thought that I had to execute the read and enter the command then, but it's the other way around.

I'm feeling a little indecisive about implementing this SAPnote. No one has authorizations to debug in change mode on the production system, except when emergency roles are assigned, and I can see how this could be useful for tackling issues that just refuse to go away. Logging via SE16N_CD_* tables appears to be sufficient. Le Sigh...

[Former Member]

>> Take note that SE16N and it's functionality is a SAP_APPL component, not SAP_BASIS!

> 604, sp03.

SAPKH60406 = 604, sp06.

> No one has authorizations to debug in change mode on the production system, except when emergency roles are assigned

The author of the note would be proud of you!

Cheers,

Julius

Edited by: Julius Bussche on Feb 12, 2010 7:28 PM

603 --> 604

[Former Member]

Note implemented in the new ECC 6.0 sanbox. Works.

Checking all activities was a bit of an overkill, no?

But still - personally I am grateful for that note. I have a lot of bad experiences with external abappers (even from SAP) who managed to grant themselves a SAP_ALL in production without having access to debug etc. but by simply toying around with function modules/exernal commands ... and then making use of SE16N - I have not been able to stop that, having no backing from the PMs. Of course, every &sap_edit is documented in the SE16*tables, but still. This is a nice, clean cut. I like it. (no more need to argue or defend my position, see? it's gone and that is that ).

One more thought: since this was ever a CO-transaction, why was it not limiited to CO-tables? Implementing it as a 'general tool' (but then only for SAP_APPL) wasn't consequent at all.

[Former Member]

I think the whole story is too long to fit into a 2500 character post..

The function should have the strictest check which the system has to offer. Which is 01 DEBUG. But in this case checking the object name is not possible, so 02 DEBUG is needed for that in the SE16N include where the function is activated. However, someone debugging another program could submit the SE16N FM from there as well, so you must at least be able to display in the debugger to get anywhere near it in the first place.

So it checks all three.

It also means that if the person does not have the authority and wants to use a dark trick to assign authorizations, they will need to go looking for SAP_ALL or possibly a multiple of authorizations to assign to pass all three checks. That is more "noisy", which is also good for finding people with fat fingers.

> why was it not limiited to CO-tables?

It does check S_TABU_DIS...?

AFAIK the popularity of the transaction (much more than just this edit feature) caught SAP by surprise and by the time it's use had exceeded imaginable boundaries... there was little chance of retro-fitting functional restrictions or a component downport to "SAP_BASIS". So authority-checks it was...

Note that the code field of SE16 is still there, as it has been since ancient times.

Cheers,

Julius

[Former Member]

>

> AFAIK the popularity of the transaction (much more than just this edit feature) caught SAP by surprise and by the time it's use had exceeded imaginable boundaries... there was little chance of retro-fitting functional restrictions or a component downport to "SAP_BASIS". So authority-checks it was... 

I don't believe that argument of retro-fitting. SAP does retro-fit other things without notifying the customers and never hesitate: for example with [note 979303|http://service.sap.com/sap/support/notes/979303] - so if they really intended something like that, they would have reacted ...

>

> Note that the code field of SE16 is still there, as it has been since ancient times. 

Just so. Of course, you are correct - still: one less battle to fight

[Former Member]

I don't think support of a mislabelled BADI used in an IS with a new alternate option is comparable to the effort of moving an extremely popular package from one component to an entirely different one, and backporting it for support down to 46C.

However I do agree with you that the correct location would be SAP_BASIS. I don't think anyone will doubt that.

Cheers,

Julius

ps: Now that you have the patch in, it will be interesting to see how "troubleshooting" is dealt with. The old SE16 route writes entries to the SM21 log (A14, A19, etc). Keep an eye out for any "go-to statement" messages and program names beginning with the character '!' (exclamation mark).

[Former Member]

>

> I don't think support of a mislabelled BADI used in an IS with a new alternate option is comparable to the effort of moving an extremely popular package from one component to an entirely different one, and backporting it for support down to 46C.

You have misread the note. This is about flagging a BADI for SAP-internal use only - and that 3 years after it's introduction to the public without notifying anyone. By this time hundreds of customers had their own implementations for that BADI which they will now have to delete ...

[Former Member]

My understanding is that the BADI's location is not correct, so they have provided a 2nd one to transfer the implementation to. A "software logistics" decision which someone took.

I still think SE16N is in a different software logistics ball park to move (the package to a different component and downport it).

Don't get me wrong - I think it would be correct.

Cheers,

Julius

[Former Member]

we can use se16n as before with a little debugging.

1)enter se16n

2) write /h enter debug mode.

Write the variables in debug mode

gd-sapedit

gd-edit

change their values 'X'.

3) run the debug and then run se16n

[Former Member]

Yep, I know about 20 other ways as well...

However you would need to run it through debug mode several times. The check on all three values is performed more than once. I suspect you only switched the edit flags in the interface to activate the edit mode. When you save, then the checks are performed again.

Cheers,

Julius

[guillaume-hrc]

Hi Julius,

Reading your post I was under the impression that the SAP_EDIT functionality was removed from the function module 'SE16N_INTERFACE' as well.

Besides, the note indicates SE37 as keyword.

Yet, although I am no longer able to use the &SAP_EDIT on my system, I still can launch the 'SE16N_INTERFACE' function module which contains an input parameter SAP_EDIT and thus, access the functionality by putting an 'X' in the SE37 Test screen.

Any thought regarding this?

Is it one of the 20 ways... ?

Best regards,

Guillaume

Edited by: Guillaume Garcia on Mar 10, 2010 2:34 PM

[Former Member]

Then you are a few months behind on support packs?

If you try to save after executing the interface, the same checks will kick in. When you apply the above note, then the save will not be possible.

Cheers,

Julius

[guillaume-hrc]

I am ! (I'm in SAPKH60006).

Seems SE16N transaction has been modified through application of so-called Security Notes (such as 1420281)

OK... guess what... I'm on a HR system... not surprising SAPKH is quite old !

I check, I am able to delete entries in my system with this FM (no check on save).

Do not understand why the note does not modify the whole thing, though ??

Best regards,

Guillaume

Edited by: Guillaume Garcia on Mar 10, 2010 3:51 PM

[Former Member]

> OK... guess what... I'm on a HR system... not surprising SAPKH is quite old !

That is strange, probably all your users with display access to the debugger can do the same then!! For HR you should be implementing legal support packs for config every year. These are delivered with all the coding SP's as well...

Anyway, there is a note to correct the interface of SE16N as well... so that leaves only about 19 ways of you are authorized for debugging in production. You can also change sy-mandt anyway.

Nothing new. Nothing special. Just usable for "kiddies" even via SE16N.

Cheers,

Julius

[Former Member]

We applied OSS note 1420281 to disable the &SAP_EDIT option in SE16N, as well as change the program status to "S" (system program) to prevent debugging for SE16 and SE16N.

Seems to be working well so far.

Create a maintenance view if you want to update table data directly.

Cheers

Shaun

[ChrisPaine]

Hello Julius, et al,

Sorry for picking up on a long since retired to bed thread, but just wanted to warn - not sure if that's the right word - you that I've quoted this thread in my recent blog. [http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/22531] [original link is broken] [original link is broken] [original link is broken];. I just came up against this change recently and it's really quite annoying. The note/code change does nothing to improve security, but just causes more hassle for genuine support use...

Anyway, it got my back up enough to need to write a short blog - and I used this thread as an example of the discussion about the change.

Cheers,

Chris