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 doesn’t 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, “kill”ing 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 parent’s 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 can’t 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 jsmith:4r556$5t$:3032:120:John Smith:/home/jsmith:/bin/csh real name userid user shell

15. Passwords • Passwords are stored encrypted • Encryption process is not reversible • can’t determine password from encryption • at least not very easily • sys admin can’t 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 0 0 0 1 owner group world 4+2+1=7 4+2+0=6 0+0+1=1 -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