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

Process Concepts How they are created and managed

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.

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.

Process IDs Numbers –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.

Process Creation Kernel swapper PID0 pagedaemon PID2 init PID1 Child Parent

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

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

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.

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);

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

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

Users and Groups Determining what you can access

Users Users are defined by two steps –making an entry in the password file –setting up a directory for the user file space jsmith:4r556$5t$:3032:120:John Smith:/home/jsmith:/bin/csh user encrypted password userid groupid real name home account shell

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

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

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

File Ownership

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

File Permissions : example ownergroupworld rwxrwx rwx = = = 1 = 761 -rwx rw- --x root other Jan thisfile owner group size filename

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

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

Processes and Users How do they relate?

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.

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

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