Chapter 4. Workstation Security

35

4.4. Administrative Controls

When administering a home machine, the user will have to 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 owner of program 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.

For a system administrator, however, choices must be made as to how much administrative access

each 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 to log in at the physical console (see the chap 

ter titled Pluggable Authentication Modules (PAM) in the Official Red Hat Linux Reference Guide for

more on 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 to trust the

users on their network.

4.4.1. 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 users means that minor issues like adding devices or

configuring network interfaces can be handled by the individual user, 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):

Machine Misconfiguration   Users with root access can misconfigure their machines and require

assistance or worse, open up security holes without knowing it.

Run Insecure Services   Users with root access may run insecure servers on their machine, such

as FTP or telnet, potentially putting usernames and passwords at risk as they pass over the network

in the clear.

Running Email Attachments As Root   Although rare, email viruses that effect Linux do exist. The

only time they are a threat, however, is when they are run by the root user.

4.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 (see Section 4.2.2 for more on this topic).

Table 4 1 shows ways an administrator can further ensure that root logins are disallowed:

Method

Description

Effects

Does Not Effect

Disabling Edit the

Prevents root access via

Since this only effects the

root SSH

/etc/ssh/sshd_config

the OpenSSH suit of

OpenSSH suite of tools, no

logins.

file and set the

tools. The following

other programs are effected

PermitRootLogin

programs are prevented

by this setting.

parameter to no.

from accessing the root

a

ccount:

ssh

scp

sftp