User guide

Administrative Controls
29
Note
The s may be upper case or lower case. If it appears as upper case, it means that the underlying
permission bit has not been set.
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 (refer to Managing Single Sign-On and Smart Cards for more information 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 not possible without
administrative privileges. As a result, system administrators must decide how much access the users
on their network should receive.
2.1.4.1. Allowing Root Access
If the users within an organization are trusted and computer-literate, then allowing them root access
may not be an issue. Allowing root access by users means that minor activities, like adding devices or
configuring network interfaces, 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:
• Machine Misconfiguration — Users with root access can misconfigure their machines and require
assistance to resolve issues. Even worse, they might open up security holes without knowing it.
• Running Insecure Services — Users with root access might run insecure servers on their machine,
such as FTP or Telnet, potentially putting usernames and passwords at risk. These services transmit
this information over the network in plain text.
• Running Email Attachments As Root — Although rare, email viruses that affect Linux do exist. The
only time they are a threat, however, is when they are run by the root user.
2.1.4.2. 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 2.1.2.2, “Boot Loader Passwords” for more
information on this topic.)
Table 2.1, “Methods of Disabling the Root Account” describes ways that an administrator can further
ensure that root logins are disallowed:
Table 2.1. Methods of Disabling the Root Account
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 any such
attempts.
The following programs are
prevented from accessing
the root account:
· login
· gdm
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