Unix Security Issues

1
Unix Security Issues

• Process Creation/Space
• Users and Groups
• File Permissions
• Relationship of Program and File Security

2
Process Concepts

• How they are created
• and
• managed

3
Programs Processes

• Program an executable
• Process(task) an instance of a program. There
  can be many!
• Multi-tasking os simultaneous execution of many
  tasks.
• Some preemptive(process gives up CPU cyclically)
• Others non-preemptive (process doesnt give up
  CPU).
• Examples
• In unix when you are running x-terminal windows,
  you can start a program in one window and go to
  work on another application in another window.
  Preemptive because all processes appear busy.
• In windows, when an application goes off to do a
  job, it will not return control to the keyboard
  (process messages) until the job finishes UNLESS
  the app is programmed to spawn threads. App must
  do it explicitly in windows.

4
Processes and IDs

• Processes have id numbers assigned by unix
• These numbers are for the purpose of
  communicating between processes, killing
  processes etc.
• These numbers are reused by the O.S. as new
  process numbers are required.
• These numbers (group and process) have NOTHING to
  do with user ids.

5
Process IDs

• Numbers 0..30000
• 0 swapper/scheduler
• 1 init
• 2 pagedaemon
• Assigned by the kernel (not a process)
• ID, ParentID, GroupID for each process.
• Other ids associated with permissions.

6
Process Creation
Kernel
pagedaemon PID2
swapper PID0
init PID1
Parent
Child
Child
Parent
Parent
Child
Child
7
Creation of Child Processes

• Created with fork()
• Child has own process id. Different from parent.
• getpid() returns your own process id
• getppid() returns parents process id
• Parent can not find child processes as easily
• fork() returns child PID to parent
• if parent dies, init process becomes parent

8
Signals

• Communicate between processes
• process to process
• kernel to process
• Signals are simple integer messages
• Process can define its own handler
• Process can choose to ignore a Signal

9
Controlling Signal handling

• signal ( signame, your function to handle)
• or
• signal(signame, SIG_IGN)
• to ignore the signal altogether
• returns a function result which is the OLD
  handler.
• save the old handler and restore when done.

10
Critical Regions
cant be interrupted in between
statements datebase updating and inserting into
lists int oldmask oldmask sigblock(mask of
signals to block) / critical region
/ sigsetmask(oldmask)
11
kill( pid, sig)

• Does NOT kill.
• Sends a signal to a process.
• pid special values (examples)
• 0 all in sending process group
• -1 all processes whose real id effective
  user of the sending process.
• AND OTHERS

12
Process Groups

• Processes are a member of a process group
• Process group is a process and all siblings
• Process group number is that of oldest (highest)
  PID
• New numbering (re)set by setgpid()
• Group id found by getpgid()
• Groups for the purpose of signalling all group
  members

13
Users and Groups

• Determining what you can access

14
Users

• Users are defined by two steps
• making an entry in the password file
• setting up a directory for the user file space

encrypted password
groupid
home account
jsmith4r5565t3032120John Smith/home/jsmith
/bin/csh
real name
userid
user
shell
15
Passwords

• Passwords are stored encrypted
• Encryption process is not reversible
• cant determine password from encryption
• at least not very easily
• sys admin cant tell you, must reset if lost
• When user logs in password is put through a
  standard encryption routine and result is
  compared with password file
• file is typically /etc/password
• exhaustive search used to crack

16
Shadow Password

• stores passwords other than in /etc/passwd
• /etc/passwd still has general read permissions to
  associate owners w/ids etc
• stores actual encrypted password in a file only
  readable by root
• allows for password aging requiring users to
  change passwords within a predetermined time frame

17
Groups

• Groups are a mechanism to share files
• Users are in a single group by default
• /etc/passwd
• Users can be members of many groups
• Owners can change the group designation of a file
• A file can only be in ONE group
• Groups (as users) are administered by root

18
File Ownership
19
Files and Ownership

• Access to files allows for degrees of use
• Three categories of ownership
• owner
• group
• world
• Access is defined by the UNION of these three
  permission sets depending on the user.
• Each file is owned by ONE user and participates
  in ONE group
• more on users and groups later

20
File Permissions example
r
w
x
r
w
x
r
w
x
761
1
1
1
1
1
1
0
0
0
owner
group
world
4217
4206
0011
-rwx rw- --x root other 34342 Jan 14 1999
thisfile
owner
group
filename
size
21
Directories

• r means the directory can be read/displayed
• w means files can be created/deleted
• x means you can traverse the directory
• if not set the directory can be part of a path
  name but not examined directly
• All users have world permissions
• Users can get additional permissions by owing or
  being part of the assigned group

22
umask

• system has a default
• users can set their own default
• shows permissions NOT allowed
• e.g. umask 0 1 1
• file would be created 766

23
Processes and Users

• How do they relate?

24
Processes and Users

• When a process is run, it runs with permissions
  of the user who launches
• It can create files if the person who runs it can
  (not the owner of the process)
• The program can be written to use setuid to
  change the userid of the person running the
  program to someone else as indicated previously.

25
Real Effective User/Group ID

• real user and group id from /etc/passwd
• effective initialized as same but can be changed
• real user/group is who is actually running
• effective is for determining permission
• owner of the file, not the user running it
• Why would you want them to be different?
• non-privileged users accessing privlg. info

26
How does this suid work?

• -rwsr-xr-x . root . passwd
• program owned by root but run by someone else
• program runs as though owned by root
• root wrote the program so allow root to do what
  it wants on your behalf (change your password)
• chmod s
• routine in program can now make suid call