firearms U.S. Army Marksmanship Unit Pistol Marksmanship Training Gu
Laymans Gu
Linux Biblia Ubuntu Fedora Debian i 15 innych dystrybucji
Anthony, Piers Incarnations of Immortality 04 Wielding A Red Sword
Werfrand
Moderna GramÄĄtica Portuguesa Evanildo Bechara
Desiree Holt [Rawh
Wiosna 1941 Ida Fink
Brust_Steven_ _Taltos
Jennifer L. Jordan Kristin Ashe Mystery 6 Selective Memory
[ Pobierz całość w formacie PDF ]
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 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 not possible
without administrative priveleges. As a result, system administrators must decide how much access the
users on their network should receive.
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 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
35
Red Hat Enterprise Linux 4 Security Guide
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 or worse, open up security holes without knowing it.
Running 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 affect 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 (refer to Section 4.2.2, Boot Loader Passwords for more
information on this topic.)
The following are four different ways that an administrator can further ensure that root logins are
disallowed:
Changing 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.
Table 4 .1. Disabling the Root Shell
Effects Does Not Affect
Prevents access to the root shell and logs Programs that do not require a shell, such as
any such attempts. The following programs FTP clients, mail clients, and many setuid
are prevented from accessing the root programs. The following programs are not
account: prevented from accessing the root account:
login sudo
gdm FTP clients
Email clients
kdm
xdm
su
ssh
scp
sftp
Disabling root access via any console device (tty)
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, because a
user can log in to their machine as root via Telnet, which transmits the password in plain text
over the network.
By default, Red Hat Enterprise Linux's /etc/securetty file only allows the root user to log in
36
Chapter 4. Workstation Security
at the console physically attached to the machine. To prevent the root user from logging in,
remove the contents of this file by typing the following command at a shell prompt as root:
echo > /etc/securetty
To enable securetty support in the KDM, GDM, and XDM login managers, add the following
line:
auth [user_unknown=ignore success=ok ignore=ignore default=bad]
pam_securetty.so
to the files listed below:
/etc/pam.d/gdm
/etc/pam.d/gdm-autologin
/etc/pam.d/gdm-fingerprint
/etc/pam.d/gdm-password
/etc/pam.d/gdm-smartcard
/etc/pam.d/kdm
/etc/pam.d/kdm-np
/etc/pam.d/xdm
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.
Table 4 .2. Disabling Root Logins
Effects Does Not Affect
Prevents access to the root account via the Programs that do not log in as root, but
console or the network. The following perform administrative tasks through setuid [ Pobierz całość w formacie PDF ]
