Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Root account controls

News

Authentication and Accounts Security

Recommended Books

Recommended Links

Reference

PAM

 Sudo

Wheel Group

Linux PAM modules

Suse Security

Red Hat security

Solaris 10  (RBAC) SecurID Tips

Humor

Etc

When administering a home machine, the user must perform some tasks as the root user or by acquiring effective root privileges via a setuid program, such as sudo  or su. A setuid program is one that operates with the user ID (UID) of the program's owner rather than the user operating the program. Such programs are denoted by a lower case s  in the owner section of a long format listing, as in the following example:

-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su 

For the system administrators of an organization, however, choices must be made as to how much administrative access users within the organization should have to their machine. Through a PAM module called pam_console.so, some activities normally reserved only for the root user, such as rebooting and mounting removable media are allowed for the first user that logs in at the physical console (see the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide for more about the pam_console.so  module). However, other important system administration tasks such as altering network settings, configuring a new mouse, or mounting network devices are impossible without administrative access. As a result system administrators must decide how much administrative access the users on their network should receive.

Allowing Root Access

If the users within an organization are a trusted, computer-savvy group, then allowing them root access may not be a bad thing. Allowing root access by users means that minor issues like related to particular application can be handled by the individual users, leaving system administrators free to deal with network security and other important issues.

On the other hand, giving root access to individual users can lead to the following issues (to name a few):

Disallowing Root Access

If an administrator is uncomfortable allowing users to log in as root for these or other reasons, the root password should be kept secret and access to runlevel one or single user mode should be disallowed through boot loader password protection (refer to Section 4.2.2 Boot Loader Passwords for more on this topic).

  Ways to disallow root logins

Method Description Effects Does Not Affect
Changing the root shell. Edit the /etc/passwd  file and change the shell from /bin/bash  to /sbin/nologin.  
Prevents access to the root shell and logs the attempt.
The following programs are prevented from accessing the root account:
login
gdm
kdm
xdm
su
ssh
scp
sftp

 

 
Programs that do not require a shell, such as FTP clients, mail clients, and many setuid programs.
The following programs are not prevented from accessing the root account:
sudo
� FTP clients
� Email clients

 

Disabling root access via any console device (tty). An empty /etc/securetty  file prevents root login on any devices attached to the computer.  
Prevents access to the root account via the console or the network. The following programs are prevented from accessing the root account:
login
gdm
kdm
xdm
� Other network services that open a tty

 

 
Programs that do not log in as root, but perform administrative tasks through through setuid or other mechanisms.
The following programs are not prevented from accessing the root account:
su
sudo
ssh
scp
sftp

 

Disabling root SSH logins. Edit the /etc/ssh/sshd_config  file and set the PermitRootLogin  parameter to no.  
Prevents root access via the OpenSSH suite of tools. The following programs are prevented from accessing the root account:
ssh
scp
sftp

 

 
This only prevents root access to the OpenSSH suite of tools.

 

Use PAM to limit root access to services. Edit the file for the target service in the /etc/pam.d/  directory. Make sure the pam_listfile.so  is required for authentication. Refer to Section 4.4.2.4 Disabling Root Using PAM for details.  
Prevents root access to network services that are PAM aware.
The following services are prevented from accessing the root account:
� FTP clients
� Email clients
login
gdm
kdm
xdm
ssh
scp
sftp
� Any PAM aware services

 

 
Programs and services that are not PAM aware.

 

 

 Disabling the Root Shell

To prevent users from logging in directly as root, the system administrator can set the root account's shell to /sbin/nologin  in the /etc/passwd  file. This prevents access to the root account through commands that require a shell, such as the su  and the ssh  commands.

 
  Important
  Programs that do not require access to the shell, such as email clients or the sudo  command, can still access the root account.

Disabling Root Logins

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty  file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous as a user can Telnet into his machine as root, sending his password in plain text over the network. By default, Red Hat Enterprise Linux's /etc/securetty  file only allows the root user to log at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command:

echo > /etc/securetty
Warning: A blank /etc/securetty  file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication.

Disabling Root SSH Logins

To prevent root logins via the SSH protocol, edit the SSH daemon's configuration file (/etc/ssh/sshd_config). Change the line that says:

PermitRootLogin yes 

to read as follows:

PermitRootLogin no 

Disabling Root Using PAM

PAM, through the /lib/security/pam_listfile.so  module, allows great flexibility in denying specific accounts. This allows the administrator to point the module at a list of users who are not allowed to log in. Below is an example of how the module is used for the vsftpd  FTP server in the /etc/pam.d/vsftpd  PAM configuration file (the \  character at the end of the first line in the following example is not necessary if the directive is on one line):

auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

This tells PAM to consult the file /etc/vsftpd.ftpusers  and deny access to the service for any user listed. The administrator is free to change the name of this file, and can keep separate lists for each service or use one central list to deny access to multiple services.

If the administrator wants to deny access to multiple services, a similar line can be added to the PAM configuration services, such as /etc/pam.d/pop  and /etc/pam.d/imap  for mail clients or /etc/pam.d/ssh  for SSH clients.

For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide.

Limiting Root Access

Rather than completely deny access to the root user, the administrator may wish to allow access only via setuid programs, such as su  or sudo.

The su  Command

Upon typing the su  command, the user is prompted for the root password and, after authentication, is given a root shell prompt.

Once logged in via the su  command, the user is the root user and has absolute administrative access to the system. In addition, once a user has attained root, it may be possible for them to use the su  command to change to any other user on the system without being prompted for a password.

Because this program is so powerful, administrators within an organization may wish to limit who has access to the command.

One of the simplest ways to do this is to add users to the special administrative group called wheel. To do this, type the following command as root:

usermod -G wheel <username>

In the previous command, replace <username>  with the username being added to the wheel  group.

To use the User Manager for this purpose, go to the Main Menu Button (on the Panel) => System Settings => Users & Groups or type the command redhat-config-users  at a shell prompt. Select the Users tab, select the user from the user list, and click Properties from the button menu (or choose File => Properties from the pull-down menu).

Then select the Groups tab and click on the wheel group, as shown below:

Next, open the PAM configuration file for su  (/etc/pam.d/su) in a text editor and remove the comment [#] from the following line:

auth required /lib/security/pam_wheel.so use_uid

Doing this permits only members of the administrative group wheel  to use the program.

Note: The root user is part of the wheel  group by default.

 The sudo  Command

The sudo  command offers another approach for giving users administrative access. When a trusted user precedes an administrative command with sudo, the user is prompted for his password. Then, once authenticated and assuming that the command is permitted, the administrative command is executed as if by the root user.

The basic format of the sudo  command is as follows:

sudo <command>

In the above example, <command>  would be replaced by a command normally reserved for the root user, such as mount.

Important: Users of the sudo  command should take extra care to log out before walking away from their machines since sudoers can use the command again without being asked for a password for a five minute period. This setting can be altered via the configuration file, /etc/sudoers.

The sudo  command allows for a high degree of flexibility. For instance, only users listed in the /etc/sudoers  configuration file are allowed to use the sudo  command and the command is executed in the user's shell, not a root shell. This means the root shell can be completely disabled.

The sudo  command also provides a comprehensive audit trail. Each successful authentication is logged to the file /var/log/messages  and the command issued along with the issuer's user name is logged to the file /var/log/secure.

Another advantage of the sudo  command is that an administrator can allow different users access to specific commands based on their needs.

Administrators wanting to edit the sudo  configuration file, /etc/sudoers, should use the visudo  command.

To give someone full administrative privileges, type visudo  and add a line similar to the following in the user privilege specification section:

juan ALL=(ALL) ALL

This example states that the user, juan, can use sudo  from any host and execute any command.

The example below illustrates the granularity possible when configuring sudo:

%users localhost=/sbin/shutdown -h now

This example states that any user can issue the command /sbin/shutdown -h now  as long as it is issued from the console.

The man page for sudoers  has a detailed listing of options for this file.

Disabling the Root Shell

To prevent users from logging in directly as root, the system administrator can set the root account's shell to /sbin/nologin  in the /etc/passwd  file. This prevents access to the root account through commands that require a shell, such as the su  and the ssh  commands.

Important: Programs that do not require access to the shell, such as email clients or the sudo  command, can still access the root account.

Disabling Root Logins

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty  file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous as a user can Telnet into his machine as root, sending his password in plain text over the network. By default, Red Hat Enterprise Linux's /etc/securetty  file only allows the root user to log at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command:

echo > /etc/securetty
Warning: A blank /etc/securetty  file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication.

 Disabling Root SSH Logins

To prevent root logins via the SSH protocol, edit the SSH daemon's configuration file (/etc/ssh/sshd_config). Change the line that says:

# PermitRootLogin yes

to read as follows:

 PermitRootLogin no

Disabling Root Using PAM

PAM, through the /lib/security/pam_listfile.so  module, allows great flexibility in denying specific accounts. This allows the administrator to point the module at a list of users who are not allowed to log in. Below is an example of how the module is used for the vsftpd  FTP server in the /etc/pam.d/vsftpd  PAM configuration file (the \  character at the end of the first line in the following example is not necessary if the directive is on one line):

auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

This tells PAM to consult the file /etc/vsftpd.ftpusers  and deny access to the service for any user listed. The administrator is free to change the name of this file, and can keep separate lists for each service or use one central list to deny access to multiple services.

If the administrator wants to deny access to multiple services, a similar line can be added to the PAM configuration services, such as /etc/pam.d/pop  and /etc/pam.d/imap  for mail clients or /etc/pam.d/ssh  for SSH clients.

For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide.

Limiting Root Access

Rather than completely deny access to the root user, the administrator may wish to allow access only via setuid programs, such as su  or sudo.

The su  Command

Upon typing the su  command, the user is prompted for the root password and, after authentication, is given a root shell prompt.

Once logged in via the su  command, the user is the root user and has absolute administrative access to the system. In addition, once a user has attained root, it may be possible for them to use the su  command to change to any other user on the system without being prompted for a password.

Because this program is so powerful, administrators within an organization may wish to limit who has access to the command.

One of the simplest ways to do this is to add users to the special administrative group called wheel. To do this, type the following command as root:

usermod -G wheel <username>

In the previous command, replace <username>  with the username being added to the wheel  group.

To use the User Manager for this purpose, go to the Main Menu Button (on the Panel) => System Settings => Users & Groups or type the command redhat-config-users  at a shell prompt. Select the Users tab, select the user from the user list, and click Properties from the button menu (or choose File => Properties from the pull-down menu).

Then select the Groups tab and click on the wheel group

Next, open the PAM configuration file for su  (/etc/pam.d/su) in a text editor and remove the comment [#] from the following line:

auth required /lib/security/pam_wheel.so use_uid

Doing this permits only members of the administrative group wheel  to use the program.

Note: The root user is part of the wheel  group by default.

The sudo  Command

The sudo  command offers another approach for giving users administrative access. When a trusted user precedes an administrative command with sudo, the user is prompted for his password. Then, once authenticated and assuming that the command is permitted, the administrative command is executed as if by the root user.

The basic format of the sudo  command is as follows:

sudo <command>

In the above example, <command>  would be replaced by a command normally reserved for the root user, such as mount.

Important: Users of the sudo  command should take extra care to log out before walking away from their machines since sudoers can use the command again without being asked for a password for a five minute period. This setting can be altered via the configuration file, /etc/sudoers.

The sudo  command allows for a high degree of flexibility. For instance, only users listed in the /etc/sudoers  configuration file are allowed to use the sudo  command and the command is executed in the user's shell, not a root shell. This means the root shell can be completely disabled, as shown in Section 4.4.2.1 Disabling the Root Shell.

The sudo  command also provides a comprehensive audit trail. Each successful authentication is logged to the file /var/log/messages  and the command issued along with the issuer's user name is logged to the file /var/log/secure.

Another advantage of the sudo  command is that an administrator can allow different users access to specific commands based on their needs.

Administrators wanting to edit the sudo  configuration file, /etc/sudoers, should use the visudo  command.

To give someone full administrative privileges, type visudo  and add a line similar to the following in the user privilege specification section:

juan ALL=(ALL) ALL

This example states that the user, juan, can use sudo  from any host and execute any command.

The example below illustrates the granularity possible when configuring sudo:

%users localhost=/sbin/shutdown -h now

This example states that any user can issue the command /sbin/shutdown -h now  as long as it is issued from the console.

The man page for sudoers  has a detailed listing of options for this file.


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

Re suauth equivalent in Fedora2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Sargent wrote:

| /etc/suauth doesn't exist in Fedora2. What is it's equivalent..?
| Cheers.

I think you are looking for sudo

Kevin Fries



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019