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

26
Unix Security Issues • Process Creation/Space • Users and Groups • File Permissions • Relationship of Program and File Security
  • date post

    20-Dec-2015
  • Category

    Documents

  • view

    246
  • download

    0

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

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..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.

Process CreationKernel

swapper PID0

pagedaemon PID2

init PID1

ChildChild

Child Child

ParentParent

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

owner group world

r w x r w x r w x

11 1111 0 0 0

4+2+1=7 4+2+0=6 0+0+1=1

= 761

-rwx rw- --x root other 34342 Jan 14 1999 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 = 0 1 1– 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