CSC662

COMPUTER SECURITY

08 - UNIX SECURITY

These slides are prepared from Prof Pavel Laskov‘s lecture slide Version 2.0

MULTICS

Multiplexed Information
and Computing Service
a high-availability,
modular, multi-component
system
secure design from
ground up: implementation
of B-LP model
initial development from
1963 to 1969; continued
until 1985; last system
decommissioned in 2000

1
 UNIX
Initial assembler
implementation by Ken
Thompson and Dennis
Ritchie for PDP-7 and PDP-
11
Rewritten in C in 1973: the
first operating system
written in a high-level
language
Continuous evolution of
various dialects of UNIX
and its routines for almost
40 years

MULTICS VS UNIX
MULTICS (Multiplexed Information and
Computing Service)
a high-availability, modular, multi-component system
secure design from ground up: implementation of BLP
initial development from 1963 to 1969; continued until
1985; last system decommissioned in 2000
UNIX: the opposite of MULTICS
initial assembler implementation by Ken Thompson
and Dennis Ritchie for PDP-7 and PDP-11
rewritten in C in 1973: the first operating system
written in a high-level language
continuous evolution of various dialects of UNIX and
its routines for almost 40 years

2
SECURITY ARCHITECTURE

DOES UNIX HAVE

SECURITY
ARCHITECTURE ?

SECURITY ARCHITECTURE

NONE!
UNIX DOES NOT HAVE
SECURITY
ARCHITECTURE

3
SECURITY AND UNIX DESIGN

Security was not a primary design goal of UNIX;

dominant goals were modularity, portability and
efficiency.
UNIX provides sufficient security mechanisms that
have to be properly configured and administered.
The main security strength of UNIX systems comes
from open source implementation which helps
improve its code base.
The main security weakness of UNIX systems
comes from open source implementation resulting
in a less professional code base.

UNIX’S LINE OF DEFENCE

Passwords are designed to prevent

unauthorized users from obtaining any
access to the system at all
File permissions are designed to allow to the
various commands, files, programs, and
system resources only to designated groups
of authorized users

4
 PRINCIPALS

User identifiers (UID)

Group identifiers (GID)
A UID (GID) is always a 16-bit number
A superuser (root) always has UID 0.
UID information is stored in /etc/passwd
GID information is stored in /etc/group

USER ACCOUNT INFORMATION:

/etc/passwd
Username: used when user logs in, 1–32 characters long
Password: ’x’ indicates that encrypted password is stored in
/etc/shadow
User ID (UID): 0 reserved for root, 1-99 for other predefined
accounts, 100-999 for system accounts/groups
Group ID (GID): the primary group ID
User ID Info: a comment field
Home directory: The absolute path to the directory the user will be
in when they log in
Command/shell: The absolute path of a command or shell
(/bin/bash)

5
 SHADOW PASSWORD FILE
Username: the user name
Passwd: the encrypted password
Last: days since Jan 1, 1970 that password was last
changed
May: days before password may be changed
Must: days after which password must be changed
Warn: days before password is to expire that user is warned
Expire: days after password expires that account is disabled
Disable: days since Jan 1, 1970 that account is disabled
Examples:

PASSWORD ENCRYPTION ON UNIX

DES
prepend password with 2-bit salt
take 7 lowest bits from first 8 characters
encrypt a fixed 64-bit string with DES using 56 bits as
a key
convert the resulting 64 bits into 11 ASCII characters
using 6 bits for character (2 bits padded with zeros)
MD5
originally written for FreeBSD to avoid export
restrictions
no limit on password size
is indicated by the starting $1$ in the shadow file

6
 GROUP FILE
Groupname: the group name
Password: an x indicates that a password is set
and if left blank no password has been set
GID: the group ID number
Members: current members of the group separated
by a comma
Examples:
root:x:0
adm:x:4:laskov
laskov:x:1000:

ROOT PRIVILEGES

Almost no security checks:

all access control mechanisms turned off
can become an arbitrary user
can change system clock
Some restrictions remain but can be overcome:
cannot write to read-only file system but can remount
them as writable
cannot decrypt passwords but can reset them
Any user name can be root!
root:x:0:1:root:/:/bin/sh
funnybunny:x:0:101:Nice Guy:/home/funnybunny:/bin/sh

7
 SUBJECTS
The subjects in UNIX are processes identified by a process
ID (PID).
New process creation
fork: spawns a new child process which is an identical process to
the parent except for a new PID
vfork: the same as fork except that memory is shared between the
two processes
exec family: replaces the current process with a new process
image
Processes are mapped to UIDs (principal-subject mapping)
in either of the following ways:
real UID is always inherited from the parent process
effective UID is either inherited from the parent process or from the
owner of the file to be executed

OBJECTS

Files, directories, memory devices, I/O

devices etc. are uniformly treated as
resources subject to access control.
All resources are organized in tree-
structured hierarchy
Each resource in a directory is a pointer to
the inode data structure that describes
essential resource properties.

8
 INODE STRUCTURE

OBJECTS

Objects represent various passive OS

entities
Security of built-in objects is managed by
OS
Security of private objects must be managed
by applications
Securable objects are equipped with a
security descriptor

9
 MODE FIELD IN DETAIL
File/resource type

Access control rules (permissions)

Examples
-rw-r--r– 1 laskov laskov 10652... 80-unix.tex
lrwxrwxrwx 1 root root 15 ... stdin -> /proc/self/fd/0
crw------- 1 laskov tty 136 ... /dev/pts/1

DIRECTORY PERMISSIONS

read: searching a directory using e.g. ls

write: modifying directory contents, creating
and deleting files and directories
execute: making a directory current and/or
opening files in it

10
 MANAGING PERMISSIONS

Octal encoding of permissions

Read-only: 100B  4
Read-write: 110B  6
Read-write-execute: 111B  7
Modifiying permissions
chmod 777 filename
chmod u+rwx,g+rw,o-w filename
Changing file owner (root only)
chown user:group filename

UNIX PERMISSIONS

11
 DEFAULT PERMISSIONS

Default permissions are usually 666 for files and

777 for programs.
umask command changes default permissions
synopsis: umask mask
the inverse of mask is added to the current permissions
Examples:

DEFAULT PERMISSIONS –
AN EXAMPLE

Mask 022 : ----w--w-

----------------------------
Inv - Not(022) : rwxr-xr-x
Def(777) : rwxrwxrwx (+)
-----------
New(755) : rwxr-xr-x
===========

12
 CONTROLLED INVOCATION
Certain actions, e.g. using system ports (1-1023) or
changing a password, require root privileges.
We don’t want to give users a general root privilege
by telling them a root password, but only the right to
run selected commands as root.
Solution: set a special flag indicating that a program
can be run under the privilege of its owner rather
than that of a calling user.
Disadvantage:this right cannot be given to selected
users: all users in the “world” (or in a group) can run
a program under its owner’s privilege.

SUID, SGID AND STICKY FLAGS

A fourth octal number is added to permissions with

the following bit designations:
SUID: set UID (allow all users to run a program)
SGID: set GID (allow all users in a specific group to run
a program)
sticky flag: only an owner (or root) can remove files in a
directory
Use chmod with four octal digits to set the extra
flags:
chmod 7644 08-unix.tex
ls –l 08-unix.tex
-rwSr-Sr-T 1 laskov laskov 13031... 08-unix.tex

13
SUID, SGID AND STICKY FLAGS -
EXAMPLE

SECURITY RISKS OF SUID

Privilege escalation
chmod 7700 bad-script.sh
chown root:root bad-script.sh
./bad-script.sh
Ownership transfer to root is forbidden!
Exploitation automatically receives root
privileges

14
 SECURE MOUNTING OF
FILE SYSTEMS
By mounting an external file system we cannot
guaranteethat it is free from malicious programs,
e.g. SUID to root programs.
As a result, access control setting may need to be
redefined for mounted media:
Security options to the mount command:
-r : read-only mount
-o nosuid : turn off SUID flags for all data in a mounted
file system
-o noexec : no program can be run from a mounted file
system
-o nodev : no character or block device can be
accessed from a mounted file system

SEARCH PATHS
A potential danger lies attacker’s diverting of
execution of a wrong program with the same
name.
Rules of conduct:
If possible, specify full paths when calling programs,
e.g. /bin/sh instead of sh
The same applied to programs to be run locally: use
./program instead of program
Make sure . is the first symbol in the PATH variable.
This will at least prevent calling a “remote” version of a
program if what you really want is a “local” invocation.

15
 PATH AND SUID COMBINED
$ cat /home/nick/bin
...#!/bin/bash
.../bin/sh #this script will execute /bin/sh
$ ls -al /usr/local/date
---s--x--x 1 root root 21673 Mar 9 18:36 date
$ PATH=/home/nick:${PATH}
$ export PATH
$ IFS=/
$ export IFS
$ /usr/local/date
# whoami
root

SECURITY FEATURES MISSING

IN UNIX
ACLs in general (getfacl only gets permissions)
Data labeling, e.g. secret, classified etc.
Mandatory access control, so that individuals are
unable to overrun certain security decisions made
by an admin (e.g. chmod 777 $Home is always
possible)
Capabilities are supported by only a small subset
of UNIX-like operating systems (e.g. Linux with
kernel versions above 2.4.19)
Standardized auditing

16
 KEY POINTS

UNIX provides a set of flexible security

mechanisms; however, their efficacy relies on
careful and knowledgable administration.
UNIX does not provide several key features
suggested by security models, e.g. no ACLs or
security levels.
The main security strength lies in its open source
implementation; hence, security flaws are
discovered and fixed early.

Thank You

17