SUSE Conversations


SUDO or not SU

maggot62

By: maggot62

July 22, 2009 5:41 pm

Reads:1555

Comments:2

Rating:0

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

  1. Edit the /etc/sudoers file. This is managed root running the visudocommand.
  2. 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'!
  3. Create a User Alias.
    User_Alias     ADMINS = will, wendy, sam
  4. Create a Command Alias ( Typically they will only need to run SU )
    Cmnd_Alias     SU = /bin/su
  5. 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
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Tags: ,
Categories: Enterprise Linux, SUSE Linux Enterprise Desktop, SUSE Linux Enterprise Server, Technical Solutions

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

  1. By:mfaris01

    Good information and ease of use.
    I do have a couple of questions…

    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?

    Thanks again for the info!

    Mike…

  2. By:maggot62

    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:

    %admingroup ALL:/bin/su

    The percent indicates a group rather than a user.

    Hope this helps

Comment

RSS