blocking su access without the -?

[Chris Hulihan]

I'd like to ensure that all users that are using su to another account are forced to 'su -' rather than just "su"... i could think of a way to alias su to 'su -' but that could easily be circumvented. Even thought of taking alias away by setting it to something else, but then someone could just launch a shell by itself and not be forced to 'su -'. any ideas?

[Rodney Hills · Accepted solution]

Usually if someone forgets the "-" their PATH variable will be unusable, so a user will not get very far running an application.

The user would then "exit" and do the "su -".

If you really want to restrict access to "su", then do the following -

First change the permissions to /usr/bin/su
to r-s------ so that only root can run it.

Create a small "c" program and call it "sux" and have it call "su -".

Set the permissions on "sux" to
r-sr-xr-x.

This will deactivate "su" from everyone except "root" and force all users to use "sux".

HTH

-- Rod Hills

[Chris Hulihan]

Thanks Rod, great answer!

[Dave Olker]

Hi Rod,

I thought about suggesting something similar to your approach, but the one thing I was concerned about was:

Set the permissions on "sux" to
r-sr-xr-x.

Wouldn't this cause the "sux" program to take on the effective uid of the listed owner of the "sux" binary itself? I think in the su case, it is really helpful to know the real user id of the user who issued the su command. I'm wondering if doing this setuid approach would cause all su logging messages in /var/adm/syslog/syslog.log to indicate that whichever user is listed as the owner of the "sux" program would be considered the user who did the su, as opposed to the real user who ran the "sux" program.

Does this make sense? Am I totally off base here (very likely)? I'd just want to ensure that from an auditing/logging standpoint whatever workaround is used would still log the su command as the real user who issued the "sux" command.

I suppose the "sux" C program could call getuid or geteuid to retrieve the uid/euid of the calling user and then use that information when calling the real su command, and that way it would ensure that the user has permissions to use the su command and switch to the user they're requesting, or gets prompted for a password for the new user. Also, this would hopefully cause the su logging to accurately reflect the user who issued the command.

Again, I could be raising a bogus issue, but the setuid stuff concerns me a bit.

Regards,

Dave

[Chris Hulihan]

Dave, good point. Obviously, in a situation where we are trying this hard to block people out of su we are going to be monitoring for su attempts.

[Jeff_Traigle]

Another possible option is to get sh-utils from the GNU project and modify their su source so it always behaves as if the "-" option is given. Then replace HP's su with that version.

Or maybe set permissions on su as Rodney suggested and set up sudo to run "su -". Since it's so strict in it's interpretation, this would prevent them from using su with the -. That would give you even more flexibility to control exactly who would be allowed to use su at all and you could track executions through sudo's log.

[Thierry Poels_1]

hi,

how about using sudo, super, nsu, .... in stead of su. You'll have better logging, better control over privileges, ...

regards,
Thierry.

[Muthukumar_5]

We can make every action related to su to su - as,

mv /usr/bin/su to /usr/bin/suorg

Note: It is good to alter the su* to stepup word so that other's can not identify it. :)
Try to change in the script of suorg to your moved su binary filename there.

cat /usr/bin/su

# Change permission to
chmod 555 /usr/bin/su
chown bin:bin /usr/bin/su

Regards
Muthu