Tài liệu Unix for Security Professionals pdf

2 - 1
Unix Security - SANS
©2001
1
Unix for Security Professionals
Security Essentials
The SANS Institute
All material in this course Copyright © Hal Pomeranz and Deer Run Associates, 2000-2001. All
rights reserved.
Hal Pomeranz * Founder/CEO *
Deer Run Associates * PO Box 20370 * Oakland, CA 94620-0370
+1 510-339-7740 (voice) * +1 510-339-3941 (fax)
/>2 - 2
Unix Security - SANS
©2001
2
Agenda
• A Brief History of Unix
• Booting Unix
• The Unix File System
• Manipulating Files and Directories
• Unix Privileges
This page intentionally left blank.
2 - 3
Unix Security - SANS
©2001
3
Agenda (cont.)
• Unix Processes
•Networking
• System Services

•Unix Backups
•Wrap-up
This page intentionally left blank.
2 - 4
Unix Security - SANS
©2001
4
The Unix File System
In this section, we look at the Unix file system, starting at the logical layers and working down to the
physical configuration of the Unix file system. Access control and file permissions are discussed and
Unix commands for manipulating files are introduced.
2 - 5
Unix Security - SANS
©2001
5
Unix File System Limits
• File names can contain any characters
except
"/" and null (ASCII 0)
• File names cannot be longer than 255
characters
• Can't specify directory pathnames
longer than 1024 characters
Like most operating systems in the last 40 years, Unix uses a hierarchical "tree-structured" file
system (interestingly, tree-structure and other aspects of the Unix file system are a direct result of
the original Unix developers being influenced by the Multics project they had been working on).
Directories contain files and subdirectories which, may in turn, contain other files and
subdirectories, and so on. The Unix file system was explicitly designed to be permissive as far as
file and directory names, so any character is allowed in a file or directory name except "/"
(which is used to specify full path names such as /etc/passwd) and null (ASCII 0, which is

the Unix string termination character).
File names can be up to 255 characters long (longer than anybody would possibly want to type).
Most Unix programs, however, won't accept pathnames longer than 1024 characters. Longer
paths than this may exist on Unix systems, but must be referenced as relative pathnames rather
than full, explicit pathnames from the root of the file system. One trivial denial of service attack
is to write a recursive program which creates a directory, changes directories into the new
directory, then creates another subdirectory, and continues this process until all file system
resources are exhausted. Clearing up such a mess is fairly tedious due to the 1024 character
pathname limit.
Another problem occurs when trying to share files from a Unix system to a machine with a more
limited file name vocabulary (like MS-DOS machines). Some algorithm must be created to
morph Unix file names into locally useful file names. The same problem happens in reverse on
MacOS systems which allow "/" to appear in folder names.
2 - 6
Unix Security - SANS
©2001
6
File Names Containing Spaces
% touch 'foo bar'
% ls
foo bar ps_data
% rm foo bar
foo: No such file or directory
bar: No such file or directory
% ls -l
total 16
-rw-r r 1 hal deer-run 0 Jun 10 10:56 foo bar
-rw-rw-r 1 root sys 4476 May 17 15:41 ps_data
% rm foo*
Another problem with the permissive nature of the Unix file naming scheme is that spaces may be

embedded in Unix file names (you see this most frequently on files imported from Windows and
Macintosh machines). Unfortunately, the Unix shell interprets space as a separator between
command arguments unless the command line is properly quoted.
In the first line of our example, we see somebody using the touch command to create a file with a
space in the name (touch is normally used to update the last modified time on a file, but as a side-
effect it will create an empty file if no file with the given name exists). A naïve user getting a
directory listing might assume that the directory actually contained three files– two of which were
named "foo" and "bar". However, attempting to remove these "two files" (or attempting to remove
the file "foo bar" without proper quoting) yields an error message. A "long listing" of the
directory shows that there are in fact only two files here, one of which has an embedded space.
At this point, the user has the option of simply issuing an rm command with proper quoting (per the
first line of the example) or using a wildcard (*) to specify "all files beginning with foo". Since
there are no other files in the directory which match foo*, this is safe to do.
2 - 7
Unix Security - SANS
©2001
7
Did You Say "Any Character"?
% touch foo\^Hbar
% ls
fobar
% rm fobar
fobar: No such file or directory
% ls -b
foo\010bar
% rm foo\^Hbar
Perhaps more evil is embedding non-printing characters in file names. In particular, the backspace
sequence (<control>-H, represented here with ^H) can cause particular fun (attackers often
create files with embedded control characters to make eradication difficult).
The user creates a file called "foobar" with a backspace between the "o" and the "b" (the

backslash "protects" the backspace from being interpreted by the Unix command shell). When an
ls is performed on the directory, the file name shows up as "fobar", not "foobar", because the
embedded backspace causes the "b" to overwrite the last "o". However the file name is really
"foo^Hbar" and cannot be removed by using the name "fobar".
On SYSV systems, ls –b shows file names with non-printing characters represented by their octal
ASCII value. You'll need an ASCII table to find out that \010 octal is ^H (man ascii on many
Unix systems will give you a Unix on-line manual page with the ASCII tables in decimal, hex, and
octal). The administrator may then remove this file using the proper key sequence. Note that
modern BSD systems generally automatically show non-printable characters as "?" in the output of
ls.
2 - 8
Unix Security - SANS
©2001
8
Know Your Unix File System
/ – root file system, top of directory hierarchy
/dev, /devices – directory containing
"files" used to talk to system devices
/usr – primary OS directory, "read-only"
/var – contains log files, queues, etc.
/tmp, /var/tmp – "scratch" directories
/usr/local, /opt – third-party software
/home, /export/home – user home dirs
Where there used to be a lot of variance in where different files were located in different Unix
"flavors", modern Unix variants have settled down to using the same general file system layout.
At the top of the directory tree is the root directory, /. Below this directory are various important
subdirectory trees. The /dev directory (SYSV systems often use /devices in addition to
/dev) contains the special files which programs running on the system use to communicate with
hardware devices controlled by the kernel. /usr is where most of the critical components of the
operating system live. This directory structure can be thought of as being "read-only"– that is,

after the operating system is loaded, not much changes under /usr unless the operating system is
upgraded or patches are installed. /var is where the system keeps data that changes frequently,
such as log files and queues for services like email and printing. /tmp and /var/tmp are
directories where any user or process on the system can write "scratch" files (many systems
automatically clean out files in /tmp that haven't been used in the last day or so). On some
systems /tmp is actually a RAM disk (in-memory file system) to increase performance of
applications that write a lot of temporary files (e.g., compilers). Non-OS software is often
installed in /usr/local (BSD convention) or /opt (SVR4), though at different sites many,
many different naming schemes are used. User home directories are often found under /home
(/home is often an NFS mounted directory with /export/home being where the files
physically reside), though /users and /u1, /u2, … are not uncommon.
2 - 9
Unix Security - SANS
©2001
9
The Root File System
• Unix kernel under root directory or in
subdirectory such as /kernel
• BSD systems store boot loader in /boot
• /sbin directory contains programs
critical for boot sequence
• /etc contains system configuration files
As we mentioned in the previous section, the root file system is where components critical for system
boot are located. In particular, the kernel itself resides near the top of the root file system: either
directly under / as /unix, /bsd, or /vmunix, or in a subdirectory such as /kernel/unix.
On BSD systems, the boot loader which actually executes the kernel during the bootstrapping
process is stored as /boot (a nasty denial of service attack is to remove the /boot program and
reboot the system– the administrator must boot off of the OS media and restore the /boot program
manually).
The /sbin directory contains the init program and the programs which init needs to configure

the system. These programs include the Unix command shell (/sbin/sh), the mount command
for mounting file systems, and the ifconfig command for configuring network interfaces.
/etc is where essentially every configuration file on the system resides (this directory tends to get
very cluttered). Note that files are often written in /etc during the boot process, so this directory
(unlike /usr) is generally considered a "read-write" directory.
2 - 10
Unix Security - SANS
©2001
10
/dev and /devices
%ls/dev
MAKEDEV fd1a rfd0Ga rwd0g tty03
MAKEDEV.local fd1b rfd0Gb rwd0h ttyC0
acd0a fd1c rfd0Gc rwd0i ttyC1
acd0c fd1d rfd0Ha rwd0j ttyC2
apm io rfd0Hb rwd0k ttyC3
apmctl ipl rfd0Hc rwd0l ttyC4
arandom ipnat rfd0a rwd0m ttyC5
audio ipstate rfd0b rwd0n ttyc0
bpf0 joy0 rfd0c rwd0o ttyc1
bpf1 joy1 rfd1Ba rwd0p ttyc2
bpf2 klog rfd1Bb rwd1a ttyc3
bpf3 kmem rfd1Bc rwd1b ttyc4
[… continues for pages …]
This is the directory listing from a BSD-style /dev directory. As you can see, the directory is full of
cryptically named files (SVR4 /devices directories are even more confusing). Generally, device
files which share the same prefix, refer to the same type of device. For example, the tty* files are
all Unix TTY drivers for different network "pseudo-terminals". The letters and numbers after a
device refer to a particular instance of the given device– for example, your system might have four
SCSI disk devices, sd0, sd1, sd2, and sd3.

Note that attackers just love to hide files and directories in /dev and /devices because they tend
to get lost in the "noise". One way to detect these directories is to write a process which periodically
calls the du (disk usage) command to report the size of the /dev directory. Generally, the size of
this directory doesn't change under normal operations, so if the disk usage spikes up (even a little), it
might be an indication that something illicit is happening in /dev.
2 - 11
Unix Security - SANS
©2001
11
/usr
• Standard OS tools in /usr/bin,
administrative programs in /usr/sbin
• System (shared) libraries in /usr/lib
• Documentation in /usr/man or
/usr/share/man
• Header files for software development
in /usr/include
Most Unix variants keep the bulk of the operating system programs in /usr/bin, however
"administrator-only" commands are often in /usr/sbin. The system libraries used to compile
programs on the system are stored in /usr/lib. Note that most modern Unix systems use the
concept of shared libraries where the library code is not actually stored in the executable itself, but
loaded out of the /usr/lib directory when the program is executed– this creates a dependency on
/usr/lib for most programs on these systems (administrators should note that programs under
/sbin are compiled without shared library support so that they can be run during the boot process
before /usr/lib is available).
On-line documentation is available in /usr/man (/usr/share/man is a SunOS convention that
is used on some other operating systems). On-line manual pages can be read using the man
command (man man for more information). man –k <keyword> will search the on-line manual
page descriptions for pages which match <keyword>.
Software developers (in addition to the system libraries in /usr/lib) will need various header files

from /usr/include. These files describe system calls and data structures used by the functions
in the system libraries.
2 - 12
Unix Security - SANS
©2001
12
/var
• System logs in /var/log (and /var/adm)
• User mail boxes in /var/mail or
/var/spool/mail (on mail servers)
• Mail queue in /var/spool/mqueue,
printer queues in /var/spool/lp*
•Files for cron daemon in /var/cron or
/var/spool/cron
BSD systems generally keep all of their log data in /var/log. SYSV systems use both
/var/log and /var/adm. Often /usr/log and /usr/adm are links to the actual directories
under /var, but the /usr pathnames are retained for backwards compatibility with older systems.
On mail servers, user mailbox files are generally stored in /var/mail (SYSV) or
/var/spool/mail (BSD). Some systems are actually configured by the administrator to put user
mailboxes in the user's home directory (generally these systems also enforce disk quotas which limit
how much disk space individual users get).
Queue directories are locations where various system processes write temporary files. For example,
print jobs in progress are put in /var/spool/lp (SYSV) or /var/spool/<printer> (BSD),
while mail messages in transit usually end up in /var/spool/mqueue. These systems use
private queueing directories rather than /tmp because the contents of the queue files are often
private and/or sensitive.
The cron daemon keeps its configuration information in /var/cron (BSD) or
/var/spool/cron (SYSV). In particular, the list of jobs to be executed for each user is often
found in /var/cron/tabs or /var/spool/cron/crontabs.
2 - 13

Unix Security - SANS
©2001
13
What Attackers Go For
/etc – back doors in inetd.conf, new
entries in passwd and shadow files
/dev, /devices – hidden directories and
config files from "rootkits"
/usr – Back-doors and changed functionality
in OS binaries after rootkit installs
/var – attackers edit log files to remove
evidence and traces of their attack
/home – .rhosts and .netrc files
From a security perspective, it's a good idea to know some of the common files and directories
that attackers will modify as part of an attack on a Unix system. The information below is just a
sampling of some common problem areas.
In the /etc directory, attackers will often try to add entries to various configuration files to give
themselves access. Look out for new entries appearing in the /etc/inetd.conf– this could
be a remote back-door into your system. New accounts in /etc/passwd and /etc/shadow,
or a change to an existing system account (like the uucp or lp accounts) might be a way for the
attacker to log into your system whenever they want.
As we mentioned earlier, attackers like to hide files in /dev because they're difficult to detect.
Often these will be the configuration and data files for "rootkits"– collections of tools attackers
like to bring onto your system. These rootkits often include malicious programs which replace
various common system binaries in the /usr file system. For example, the attacker might bring
in a replacement Syslog daemon which doesn't log information about the attacker’s activities!
After a successful attack, attackers will also edit your log files in the /var file system to cover
their tracks. It's often a good idea to log information to another system as well as the local
machine, so you can compare copies of the logs after a break-in.
.rhosts files in a user's home directory can allow an attacker to access the system as that user

remotely without providing a password– as long as the system that the attacker is coming from is
listed in the .rhosts file. .netrc files are used by FTP to do automated login "scripts"– they
can contain passwords that an attacker can use to break into other systems.
2 - 14
Unix Security - SANS
©2001
14
File Attributes
% ls -ld /etc /boot
-r-xr-xr-x 1 root wheel 45056 Nov 3 1998 /boot
drwxr-xr-x 12 root wheel 2048 Jun 10 11:35 /etc
File
Type
Permissions
Link
Count
Owner
Group
Owner
Size
(bytes)
Last
Modified
File
Name
Now let's turn our attention to Unix file attributes as shown by the ls program. The –l argument
(that's an "el" not the numeral 1) forces the detailed output listing shown above, and the –d flag tells
ls to list information about a directory rather than information about the contents of the directory
(the default).
The first column of the listing is a block of letter codes showing the type of file and the access

permissions set on the file. We'll return to file permissions soon, but as far as file types go there are
7 one-letter codes: '-' (regular file), 'd' (directory), 'l' (symbolic link– that's an "el" for "link", not a
one), 'c' and 'b' (special Unix device files– see next slide), 'p' and '|' (named pipes and FIFOs which
will not be discussed in this course). The next entry is the link count field which will be discussed
towards the end of this section.
The next two columns show the owner of the file and the group owner of the file. These combine
with the file access permissions to tell the system who has access to the file.
The fifth column is the file size in bytes. Next comes the last modified time on the file. Note that
dates within the last year display the actual time of modification while older dates simply display
month, day, and year. This is simply a human readable formatting decision– actual Unix dates are
stored in a completely different internal format.
The last column displays the file name.
2 - 15
Unix Security - SANS
©2001
15
Symbolic Links and Devices
% ls -l /dev/kmem /devices/pseudo/mm@0:kmem
lrwxrwxrwx 1 root other 25 Jun 8 12:58
/dev/kmem -> /devices/pseudo/mm@0:kmem
crw-r 1 root sys 13, 1 Jun 8 12:58
/devices/pseudo/mm@0:kmem
File
Type
Device
Numbers
Path to
Real File
Certain special types of files provoke slightly different output formats from the ls command.
The convention of having a symbolic link in /dev pointing at a real device file under

/devices is a SVR4 mechanism for backwards compatibility for Unix applications expecting
certain device names under /dev.
Symbolic link files (note the 'l' in the first position of the listing) display both the name of the
link as well as the name of the file that the link points to. Notice that there are 25 characters in
the path name /devices/pseudo/mm@0:kmem and that the size of the symbolic link "file"
as reported by ls is 25 bytes– symbolic link "files" simply contain the path of the file that they
point to.
Device files on a Unix system don't contain any actual data, so instead of displaying a file size,
the ls command displays the device numbers corresponding to the device. The first number (the
major device number) indicates what sort of device this is (the number is actually the index of the
device driver code in the Unix kernel for the given device) and the second number (the minor
device number) specifies a particular instance of the device. Generally speaking, all devices of a
certain type– SCSI tape drives for example– will have the same major device number but the
individual tape drives connected to the system will each have their own minor device number.
Note that device numbers are architecture-specific and not portable from vendor to vendor or
even between different hardware platforms from the same vendor (can't use the same device
numbers for Sun Ultra5s and E10Ks).
2 - 16
Unix Security - SANS
©2001
16
Unix File Permissions
x-rx-rxwr
File
Owner
Group
Owner
Everyone
Else
Write

Permission
Read
Permission
Execute
Permission
Unix file permissions use a fairly coarse granularity security model. Read, write, and or execute
permissions can be set for three different categories of people: the file's owner, people belonging to
the Unix group listed as the group owner of the file, and "everybody else" (or "other").
Read permission means the ability to look at the contents of the file, write permission means the
ability to modify the contents of the file, and execute means that the file may be run as a program.
Note that a user may execute a file as long as they have execute permission, even if they cannot
"read" the file.
2 - 17
Unix Security - SANS
©2001
17
Other Permission Bits
t-rs-rswr
File
Owner
Group
Owner
Everyone
Else
Set-UID Set-GID "Sticky"
There are three other permission flags that may be set on a file.
Certain programs need to run with special access privileges not available to normal users– for
example, the passwd command which changes a user's password needs administrative privileges so
it can update the system password database. The set user ID (set-UID) and set group ID (set-GID)
flags cause the program to run as the owner or group owner of the file, rather than as the user that

executed the program– the passwd program is set-UID and owned by the Unix administrator account
(root), so that it can update the password database when executed by a normal user. Set-UID and
set-GID programs are often a source of security problems on Unix systems but are still one of Unix's
most useful innovations.
The so-called "sticky bit" was originally developed in the early days of Unix on slower machines.
The idea was that any program which had the sticky bit set was supposed to "stick around" in the
memory of the operating system after the program had finished executing. This was a win on
programs that needed to be executed frequently because they didn't need to be constantly read back
into memory. Modern Unix systems (which use shared libraries, have better caching algorithms, and
run on faster hardware) generally ignore the sticky bit on executables. However, the sticky bit now
has a different special meaning when applied to directories.
2 - 18
Unix Security - SANS
©2001
18
Files vs. Directories
only owner may
remove files
N/A
"Sticky"
group ownership of
new files is inherited
as above but for group
owner
Set-GID
N/A
file executes with
privileges of file's owner
Set-UID
may access files in

directory
may execute file
Execute
can create/remove filescan modify file contents
Write
can get directory listingcan read file contents
Read
DirectoryFile
Because the Unix file permissions model is fairly limited, the meaning of each of the permissions
flags we've seen so far is "overloaded", having different behavior depending on whether or not
the object is a file or directory.
For example, being able to "read" a directory means that the user can run the ls command (or
other similar commands) to get a listing of the files in the directory. Write permissions on a
directory give the user permissions to change elements of the directory "file"– as we will see
shortly, Unix directories contain file names and pointers to files, so being able to modify
directories means being able to change file names and/or add and remove files. The execute bit
on a directory gives the user the ability to change directories into the given directory and to
access files out of that directory, but a directory listing cannot be obtained unless the read
permissions are also set. Generally speaking, directories need the execute flag turned on to be
useful but it is sometimes appropriate to give a user only execute rights on a directory (if you
want the contents of the directory to be private and give the user just one explicit file path to
access).
If the set-GID bit is set on a directory and a user creates a new file in that directory, then the
group owner of that file will be the group owner of the directory rather than the primary group
that the user belongs to– this is useful when you are using Unix groups as a mechanism for
sharing files in a large project. When the sticky bit is set on a directory, then only the owner of a
given file may remove that file from the directory– this bit is often set on /tmp and other
temporary directories to prevent users from stomping on each other's files (either accidentally or
on purpose).
2 - 19

Unix Security - SANS
©2001
19
Absolute File Modes
x-rx-rxwr
File
Owner
Group
Owner
Everyone
Else
101101111
7
55
Unix access permission flags are often referred to as "bits" because their representation in the Unix
operating system is as binary value– a one means the given flag is turned on and a zero means the
flag is not set. Unix commands which affect the permissions on files usually use octal notation to
represent the clusters of bits for the owner, group owner, and "other" categories. The octal notation
completely specifies all of the permission bits on a file and so is generally referred to as the absolute
mode of the file.
In the example above, the owner of the file has read, write, and execute permission: all bits are
turned on so the binary representation is "111", which is octal 7 (4+2+1). The group owner and
"other" category only have read and execute set, but not write permissions: the binary is "101" which
is 5 octal (4+1).
2 - 20
Unix Security - SANS
©2001
20
Using Absolute Modes
•With

chmod
command:
chmod 666 myfile
chmod 1777 /tmp
•"Inverted" for
umask
command
umask 022
umask 077
The chmod (change mode) command sets permissions on a file or directory. The first example
shows how we can use absolute mode to set read and write permissions for all categories of users on
a given file and "give away" that file to anybody on the system. Making a file "world-readable" in
this way is dangerous– particularly if the file contains logging information or system configuration
data. Note that the set-UID, set-GID, and sticky bits are represented in a fourth optional octal digit at
the beginning of the absolute mode (set-UID is 4, set-GID is 2, and sticky is 1). In our second
example we set the normal permissions on the /tmp directory– anybody on the system has read,
write, and execute permissions on the directory but the sticky bit is set so that users can't clobber
each other's files.
The umask command allows a user to specify what permissions they want to be set by default on the
files that they create. The umask command specifies the bits that should be turned off when the file
is created. For example, a umask of 022 specifies that the write bit should be turned off for the
group owner and the "other" category. This means that new regular files will be created with the
read bit turned on (absolute mode 644) and that new programs will be created with the read and
execute bits turned on (mode 755). umask 022 is the standard "friendly" umask. However,
some users may wish to not allow anybody but themselves to access their files by default, so setting
the umask to 077 turns off all bits except those which apply to the file's owner.
2 - 21
Unix Security - SANS
©2001
21

Symbolic Mode with chmod
• Remove set-UID flag:
chmod u-s myfile
• Add group write permissions:
chmod g+w myfile
• Don't let other people read the file:
chmod o-r myfile
• Turn off execute bit for everyone:
chmod a-x myfile
chmod also supports symbolic mode which allows administrators to turn individual bits on and off.
The first part of the symbolic expression specifies the category of the bit: 'u' (user) for the file owner
permissions, 'g' for the group owner, 'o' for the "other" or "everybody else" category, and 'a' for all
categories. Next is a plus or a minus which says whether the bit should be turned on or off. Finally
the actual bit is specified ('t' is used to denote the sticky bit because 's' is used for set-UID and set-
GID).
Note that the "a" group specifier can usually be dropped. Thus chmod a-x myfile and chmod
–x myfile do the same thing on most Unix systems.
2 - 22
Unix Security - SANS
©2001
22
User and Group Ownership
• chown changes file ownership
chown hal /home/hal
• chgrp changes group ownership
chgrp other /home/hal
• Usually, you can do both at once
chown hal.other /home/hal # old BSD
chown hal:other /home/hal # modern
The chown command changes the owner of a file, the chgrp command changes the group owner.

Actually, the chown command can set both the owner and group owner simultaneously as shown
above– on 4.3BSD-derived systems (and older, e.g. SunOS) the separator between the owner and
group owner is '.', but on newer machines (and SYSV-derived machines in general) the character is
':'.
On some Unix machines any user can run chown. On these systems, however, running chown
usually clears the set-UID and set-GID bits or else normal users could create files that were set-UID
to the administrator account and compromise the system. Allowing users to run chown to "give
away" their files can cause many other problems as well– including thwarting the disk quota system
(users can chown their files to somebody else to give themselves more disk space or wage a denial-
of-service on another users). Modern BSD-derived Unix systems generally only allow chown to be
run by the Unix administrative user.
2 - 23
Unix Security - SANS
©2001
23
Common Settings
• Most system files should be owned by
the root user
• Group owner is often sys, bin, or root
• Files should generally only be writable
by their owner
• Look out for set-UID files – especially
set-UID files that "suddenly" appear
Most executable files on a Unix system are mode 755, while regular files tend to be mode 644.
Certain "private" files on the system, however, are only readable by the owner– for example
/var/log/secure under Linux (contains sensitive log data) which is owned by the
administrative user and is mode 600, or the /etc/shadow file on many Unix systems (stores
encrypted passwords) which is mode 400. Generally files should never be "world-writable" (mode
666), because then any user on the system could modify them. Also be on the look out for files that
have the set-UID or set-GID bits set, since these have the highest potential for causing harm. Be

especially concerned if a new set-UID program suddenly appears on your system– maybe in a user's
home directory or in some other unusual location. A little bit later, we'll give you a command that
allows you to locate all of the set-UID and set-GID files on your system.
Binaries and other files that ship with your operating system are most often owned by the Unix
administrative user, root. Usually the group owner is sys or root, but sometimes bin. Be on
the look-out for files in the standard operating system directories that are owned by other users.
2 - 24
Unix Security - SANS
©2001
24
The Physical File System
• The logical Unix file system is made up
of multiple physical disk partitions
• Disk partitions are mounted at various
points in the file system
• A typical disk (on Solaris) has eight
partitions, but one is reserved
While the logical file system appears as one single entity to users on the system, it is actually
made up of several pieces (partitions) which correspond to physical sections of the machine's
disk drives. A given partition corresponds to a certain directory structure– for example you might
have one partition for the root file system, another for /usr, another for /var, and so on.
During the boot process, init mounts all of these partitions into their proper place in the file
system– disk partitions and their mount points are generally described in a file called
/etc/fstab (BSD) or /etc/vfstab (SVR4).
From a Unix perspective, disk drives have eight different partition "slices" (either lettered a-h or
numbered 0-7, e.g. "sd0c" for the third slice of SCSI disk 0). Newer BSD-derived systems
allow sixteen partitions per disk. One slice is generally reserved as the "overlap" partition which
represents the entire disk geometry (by convention this is usually the third slice of the disk
because early Unix systems required the first slice to be the root file system and the second slice
to be the swap space for the virtual memory system). This slice should not be used for file

systems. Note that not all possible disk partitions need be used– you might just create a single
partition that spans an entire disk and ignore the other slices.
Partitions were created to solve two problems. One was to make it more difficult for problems
with one subsystem (like the logging processes in /var) to cause a denial of service to other
processes (like compilers writing files in /tmp). The other was to make backups easier: some
partitions like /usr rarely need to get backed up, whereas user home directories might need to
get backed up every night. If your vendor (HP or Sun, for example) tells you that you don't need
to partition your file system, they're dead wrong.
2 - 25
Unix Security - SANS
©2001
25
The df Command
% df -k -t ffs
Filesystem 1K-blocks Used Avail Capacity Mounted
/dev/wd0a 29703 14891 13327 53% /
/dev/wd0d 257647 148898 95867 61% /usr
/dev/wd0e 495663 9397 461483 2% /var
/dev/wd0g 7046057 649332 6044423 10% /home
Disk
Device
Partition
Total Size
Space
Used
Available
Space
Percent
Full
Mount

Point
You can display the currently mounted file systems with the df command– df stands for "disk
free" and was really created to allow administrators to know if they were running out of disk
space. The command line in this example tells df to show all partitions which are of type ffs
(the standard Berkeley fast file system) and to display the output in kilobytes (-k) rather than
the default (disk blocks of 512 bytes each). SVR4 systems use –F ufs (Unix file system–
though really all modern Unix machines use the FFS code developed by BSD) instead of –t
ffs.
The first output column shows the disk device associated with the partition. The next column is
the total usable space in the partition (which is smaller than the actual physical size of the
partition due to space reserved for control information). Next are the number of bytes used and
the number of bytes available, and the percentage of free disk space. The attentive reader will
note that (bytes used) + (bytes available) is not equal to the total size of the partition– the Fast
File System reserves 10% of the total partition because FFS performance suffers if the disk
becomes too full. When a partition gets to 90% full, no user except the administrator is allowed
to write data into the file system. Note that the capacity figure uses 90% of the total partition
size as the denominator, so it shows 100% full when the partition is actually only 90% full.
Note that we are using df here to only show us local disk partitions, but df can also display
information about NFS partitions (-t nfs) and other more specialized file systems. The
default for df is to display information about all partitions on the system: FFS, NFS, or
whatever.