LPI Linux Certification in a Nutshell (63 page)

Although SUID is a useful option when it comes to
delegating roles to nonroot users, its potential security
vulnerabilities should not be overlooked. A program marked with the SUID
bit and owned by root will run as root. Everything that that program is
able to do will be done as the root user. This has large implications
for the overall security of a system. Think of this example:
vi
is a common editor that is found on most Linux
systems. If
/bin/vi
is SUID, every user who edits
any file with
vi
will have the privileges of the
root user, meaning that any user could edit
any
file on the system. This is the kind of thing that makes SUID so
potentially dangerous. There is a situation worse than being able to
edit any file as root: spawning a subshell from an SUID program. We can
use
vi
as our example here again. The editor
vi
allows you to issue a command to spawn a
subshell while you are in the editor. We know that a child process
inherits the security context of the parent process. So if
vi
is SUID and it spawns an interactive shell child
process, that interactive shell has a security context of
root
. So the simple act of making
/bin/vi
SUID has given all users on the system an
easy way to access an interactive shell prompt as the root user,
completely undermining all other security protocols that might be in
place.

Because of this potentially dangerous situation, a good system
administrator must be aware of what programs on his system have the SUID
and/or SGID bit set. The
find
command (described in
depth in
Chapter 6
)
has an option to search for files based on their permissions. Here is an
example:

#
find /bin -perm -4000 -type f
/bin/mount
/bin/su
/bin/ping
/bin/ping6
/bin/umount
/bin/fusermount

The
-perm -4000
option to
find
says, “Only display files that have the SUID
bit set.” The number 4000 is the octal representation of the security
mode for a file. Reading from right to left, the first 0 is for “other”
permissions, the next 0 is for “group” the third 0 is for “owner,” and
the 4 represents SUID. An equivalent way to write this using symbolic
modes instead of the octal representation is
-perm
–u=s
, as in “find all files that have the ‘s’ bit set in the
user mode section.”

It is important to understand why some programs have the SUID bit
set. Some programs (such as
ping
) are not required
by the operating system, and it is therefore safe to remove the SUID bit
from them. Some programs (such as
passwd
) need to
be SUID to ensure they function correctly on the operating system (if
you remove the SUID bit from the
passwd
command,
then users cannot change their own passwords). If the SUID bit is not
required in your situation, remove it:

#
ls -l /bin/ping
-rwsr-xr-x 1 root root 42360 2008-09-26 01:02 /bin/ping
#
chmod -s /bin/ping
#
ls -l /bin/ping
-rwxr-xr-x 1 root root 42360 2008-09-26 01:02 /bin/ping
#

Now only the superuser will be able to use the
ping
command.

In addition to the SUID and SGID bit, the commands
su
and
sudo
can be used to
elevate the privileges of a regular user.

Users in the Unix world are most commonly referred to by
their
usernames, but that is not how the underlying operating
system sees them. Every user on a system is assigned a user ID (UID)
that uniquely identifies that user. UIDs are integers ranging from 0 to
65535. UID 0 is reserved for the superuser (commonly named
root
, but the name can in fact be anything, as long
as the UID is 0). Convention dictates that “system” users (user accounts
that represent system processes, not actual human beings) have UIDs
below 100.

Because everything in Unix is a file, the file security
permissions are of utmost importance. The owner and group owner of a
file is stored in the inode (index node) at the filesystem level. This
is stored as the UID integer, not as the username. To see an example of
this, do a long directory listing on a directory where some files are
owned by users that no longer exist on the system:

#
cd /var/spool/mail/
#
ls -l
total 1295140
-rw-rw---- 1 adamh       mail         0 Jan  6 11:04 adamh
-rw-rw---- 1 alex        mail  86311334 Jan  8 06:27 alex
-rw-rw---- 1        2047 mail         0 Dec  2  2006 alice
-rw-rw---- 1        2003 mail   1600945 Jan  7  2009 bob
-rw-rw---- 1        2080 mail     95086 Sep  9  2008 carol

In this example, we are looking in the directory
/var/spool/mail
, where the mail spool files
for each user are stored, with filenames corresponding to user account
names. The files
adamh
and
alex
are owned by users
adamh
and
alex
, respectively,
whereas the file
alice
is owned by
UID 2047,
bob
is owned by 2003, and
carol
is owned by 2080. This reflects the fact that
ownership is stored in the inode by integer (the UID). In this case, the
users
alice
,
bob
, and
carol
no longer have accounts on the system, but
these files still reflect that they are owned by these (now unassigned)
UIDs. The
ls
command will display the username
instead of the UID by default in a long directory listing (unless the
-n
option is passed to
ls
)
because we human beings are better at remembering names than numbers. If
ls
is able to resolve a UID to a username, it will
display the username; if not, it displays the UID.

The file
/etc/passwd
acts as
the source for username-to-UID mapping (unless a system such as NIS is
in use, which is not covered on LPI 102). This file is the source for
all user accounts on the system, and contains not only username
information, but also other information about the user account, such as
that user’s home directory and default shell. The following is an
example section from
/etc/passwd
:

#
more /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
adamh:x:500:504:Adam Haeder:/home/adamh:/bin/bash

Each colon-delimited line represents one user account.
Table 22-1
defines these
fields.

Let’s take a look at the user
adamh
from our
previous example:

adamh:x:500:504:Adam Haeder:/home/adamh:/bin/bash

Field 3 tells us that the UID for
adamh
is
500, and field 4 tells us that the GID for
adamh
is
504. Many Linux distributions will start “normal” user UIDs at 500,
reserving UIDs from 1–499 for system accounts. Field 5 tells us that his
full name is Adam Haeder, field 6 says his home directory is
/home/adamh,
and finally, field 7 says that
when he successfully logs in, the program
/bin/bash
will be executed.

/etc/passwd
is a text file,
and therefore it can be edited like any other text file. However, that
is a bad practice to get into because a syntax error in this file can
prevent users (even
root
) from logging into the
system. A much better way to maintain the
/etc/passwd
file is with the command
/usr/sbin/usermod
.