SUDO or not SU

Security is weakened when the root password is known, as administrators leave they may still have the root password and access to the system. Rather than give administrators the root password; why not consider assigning them the ability to run /bin/su via the sudo command? This way you do not need to divulge the root password. Yes, administrators would have the ability to change the root password, however, in most cases they can be trusted and would not breach that trust and would be no different if they had been given the root password in the first place.

The concept now is when an administrator leaves or needs to return administrative rights, a simple edit to the /etc/sudoers file will disable the ability of the user to run the su command. There is no mechanism for the user to discover the root password, so your system remain secure. In the same way an administrator can be added to the sudoers file to gain access

Edit the /etc/sudoers file. This is managed root running the visudocommand.

Ensure the SUSE defaults are commented out

# In the default (unconfigured) configuration, sudo asks for the root password.
# This allows use of an ordinary user account for administration of a freshly
# installed system. When configuring sudo, delete the two
# following lines:
#Defaults targetpw # ask for the password of the target user i.e. root #ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!

Create a User Alias.

User_Alias ADMINS = will, wendy, sam

Create a Command Alias ( Typically they will only need to run SU )

Cmnd_Alias SU = /bin/su

Allow Admins to run SU

ADMINS ALL = SU

The “group” ADMINS now can run the command /bin/su from sudo now. They will be prompted for their own password not that of root!

sudo su -

You can also consider removing the SUID bit from the su program

chmod u-s /bin/su

(0 votes, average: 0.00 out of 5)You need to be a registered member to rate this post.

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up). It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

2 Comments

How would this work in a LUM environment?
How would I make my eDirectory LUM enabled “admingroup” have the same access, like in your example? Or would I have to set up something entirely different because they wouldn’t have “local” accounts?

Thank you for your time to make the comment Mike. LUM users and groups are kind of treated as local users. When LUM is installed as part of OES the /etc/nsswitch file will have an entry to show how the passwd file will be used. The passwd file contains users. For LUM it will have an entry:

passwd: compat nam

Meaning it will first search for users in the compatible file ie /etc/passwd then used nam ( Novell Account Manager ) the old name for LUM.

The same for groups.

The easiest way to use existing Liniux groups ( or LUM enabled groups ) will be to not woork about the User_alias. Just add a line similar to this: