LPI Linux Certification in a Nutshell (63 page)
Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
A system is only as secure as the administrator. Although some
operating systems may claim better security than others, this is always the
“out-of-the-box” type of security. Any system, no matter how secure
initially, can become insecure if poorly maintained. It is the
responsibility of the system administrator to take an active hand in
security, and address both active and passive threats. As with most things,
the first step is knowledge. Understanding how your system works and what
tools are available is fundamental to securing your system. This chapter
covers the first Objective of Topic 110:
- Objective 1: Perform Security Administration
Tasks Candidates should know how to review system configuration to
ensure host security in accordance with local security policies. This
includes topics such as SUID/SGID bits, password aging and good
password policy, discovery tools such as
nmap
,
netstat
, and
lsof
, limiting
user actions, and giving select users elevated privileges. Weight:
3.
Since everything in Linux is a file, filesystem level
security is a core concept that must be understood and implemented
properly. The standard Unix security model (which most Linux file systems
adopt) is a relatively simple permissions-based model, but it is
sufficient for most permissions needs. For more information on the details
of the Unix permissions-based security model, refer to the section
Changing access modes
.
When a user executes a program in Linux, that program is spawned as
a subprocess (or subshell) of the user’s current shell. This subprocess is
known as a
child
process
, and is defined in depth
in the section
Objective 5: Create, Monitor, and Kill Processes
. From a security
standpoint, the important thing to remember about child processes is that
they inherit the security context of the parent process. So if the user
adam
executes a program, that program
will have access to the same files and directories that the user
adam
normally has (no more, and no less).
However, this is not always a desirable situation. One of the
criticisms of the stan
dard
Linux
security model is that it is not fine-grained enough, i.e., you’re either
a regular user with little or no privileges, or you are the superuser
(root) with all privileges. Often, we want the ability to elevate certain
users to superuser status for short periods of time, or to execute certain
commands, or we want certain commands themselves to execute with elevated
privileges, regardless of who executes them. There are ways to handle all
of these situations in Linux: SUID and SGID bits, and the commands
sudo
and
su
.
Changing access modes
describes the different
security modes that are available to files in Linux. These are normally
read, write, or execute. One of the “special” modes available is
s
. When the mode
s
is assigned
to owner permissions on an executable file, we say that file has the SUID
(or SetUID) bit set. When the mode
s
is assigned to
group permissions on an executable file, we say that file has the SGID (or
SetGID) bit set.
SUID means that no matter the security context of the parent process
running the executable, the executable will run with the security context
of the owner of the executable file. This is most commonly used to give
regular users the ability to run programs that require root access without
actually giving them access to the root account. So if an executable file
has the SUID bit set and the file is owned by root, then no matter who
executes that file, the resulting process will have
root
-level
permissions
.
An example of this is the
ping
command.
ping
is used to send ICMP packets to hosts on a network and report back on
replies. It is primarily a network testing tool, and is a standard part of
every operating system that supports TCP/IP.
Ping
needs the ability to open a raw network socket in order to do its job, and
that kind of low-level access is reserved for the root user. However, it’s
such a useful and ubiquitous tool, it’s common to want to make it
available to all users on a system. So in many Linux distributions,
ping
has the SUID bit set by default. Any user that
runs the
ping
command will run it in the security
context of the root user.
Here is what a directory entry for
ping
looks
like:
$ls -l /bin/ping-rwsr-xr-x 1 root root 42360 2008-09-26 01:02 /bin/ping
Thesin the user section of the
file security setting means that the SUID bit is set.
SGID works in the same way, but for group ownership instead of user
ownership.
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 -ltotal 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/passwdroot: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.
Table 22-1. Fields in /etc/passwd
Field | Name | Description |
|---|---|---|
1 | Username | A human-readable name, 1–32 characters |
2 | Password | Formerly stored a user’s encrypted |
3 | User ID (UID) | The integer from 0–65535 that |
4 | Group ID (GID) | The integer from 0–65535 that |
5 | Comments | Textual information about a user. This |
6 | Home | The absolute path to the directory the |
7 | Default shell | The program that runs when the user |
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
.
