Chapter 4. Protection in General-Purpose Operating Systems. ch. 4 1

Transcription

1 Chapter 4 Protection in General-Purpose Operating Systems ch. 4 1

2 Chapter Outline 4.1 Protected Objects and Methods of Protection 4.2 Memory and Address Protection 4.3 Control of Access to General Objects 4.4 File Protection Mechanisms 4.5 User Authentication 4.6 Summary of Security for Users ch. 4 2

3 Introduction OS still software ch. 3 vulnerabilities still apply OS must protect users from each other memory protection file protection general control and access to objects user authentication ch. 4 3

4 Chapter Outline 4.1 Protected Objects and Methods of Protection 4.2 Memory and Address Protection 4.3 Control of Access to General Objects 4.4 File Protection Mechanisms 4.5 User Authentication 4.6 Summary of Security for Users ch. 4 4

5 Fundamental Tradeoff operating systems tradeoff between: sharing protection sharing is desirable protection is difficult ch. 4 5

6 Early History no OS programs entered directly in binary through switches user s program only one on system user responsible for: loading dependent libraries, other tools scheduling time to use computer ch. 4 6

7 later machines very expensive people less expensive maximize use of machine allow many users ch. 4 7

8 multiple users. protection. multiple users need protection prevent A from writing on B s stuff B from writing on A s stuff A, B from writing on the OS ch. 4 8

9 protect what? memory sharable I/O devices, e.g., disks serially reusable I/O devices, e.g., printers, tapes shared programs, libraries networks sharable data ch. 4 9

10 OS protection. separation. physical separation, e.g. 1 user/printer temporal separation logical separation user thinks own machine cryptographic separation combinations of these ch. 4 10

11 levels of protection no protection isolation share all or nothing share via access limitation share by capabilities limit use of an object ch. 4 11

12 no protection e.g. early versions of windows some embedded environments ch. 4 12

13 isolation processes unaware of other processes each process: own address space, files, etc. OS provides confinement virtual machines ($100 laptop) ch. 4 13

14 share all or nothing owner of object declares it: public available to all users private not available ch. 4 14

15 share via access limitation Access control lists Access Control Matrices Capabilities ch. 4 15

16 limit use of an object sophisticated access control examples: can view a file, but can t print given aggregate info from database, but not individual records ch. 4 16

17 granularity at what level to protect? byte, word, field, record, file, volume? fine granularity more control but more complex more overhead ch. 4 17

18 Chapter Outline 4.1 Protected Objects and Methods of Protection 4.2 Memory and Address Protection 4.3 Control of Access to General Objects 4.4 File Protection Mechanisms 4.5 User Authentication 4.6 Summary of Security for Users ch. 4 18

19 Memory and Access Protection Fences Relocation Base/Bounds Registers Tagged Architecture Segmentation Paging Combined Paging with Segmentation ch. 4 19

20 Fences protect OS from user program confine users to one side of a boundary predefined memory address user code on one side OS on the other problem fixed boundary too restrictive doesn t protect users from each other moveable fence: store fence location in fence register os space user space ch. 4 20

21 Relocation programs written to run starting at address 0 can be run at any address addresses in source are symbolic: e.g., numstudents compiler binds these to relocatable addrs. e.g. 20 bytes from beginning of module func then linker or loader binds to absolute addresses e.g logical addresses mapped to physical by MMU program never sees real addresses ch. 4 21

22 address limits moveable fence register: base register stores smallest legal physical memory address i.e., lower bound bounds register stores upper address limit or limit register make sure each access falls within range base, limit registers only accessible by OS access through privileged instruction fragmentation is a problem though ch. 4 22

23 base/bounds registers base register j+1 k bounds register etc. addresses 0 j j+1 k k+1 etc. OS prog A prog B prog C ch. 4 23

24 program segment base/bounds goal of base/bounds registers confine program to own address space what about within an address space? errant program can still write data over own instructions base/bounds within a single address space: confine instructions to program segment confine data to data segment ch. 4 24

25 program segment base/bounds ch. 4 25

26 tagged architecture set of bits for every memory word permissions R read RW read/write X execute can also be used to label data type not common in modern systems ch. 4 26

27 segmentation intro memory is an array of bytes programmers don t usually see this way instead, think of chunks like modules classes functions data structures ch. 4 27

28 Segmentation ch. 4 28

29 why segmentation? any segment can be loaded anywhere in physical memory shared segments e.g. on multi-user system: text editor common libraries don t need to load multiple copies same protection for entire segment e.g. read-only program segment, rw for data, ch. 4 29

30 how to do segmentation? logical addr. space = group of segments each segment has a: name length logical address = <seg. number, offset> segment table maps logical address to physical address logical address <seg#,offset> physical 2 dimensional space ch one dimensional

31 how to do segmentation? ch. 4 31

32 paging divide program into equal-sized pieces logical pieces called pages physical pieces called frames MMU helps map logical to physical page size typically power of Bytes to 16 MBytes helps minimize fragmentation common in modern operating systems ch. 4 32

33 paging page #, index in page table ch offset in page same as offset in frame

34 why page size power of 2? convenient if page size is a power of 2, say 2 n logical address low order n bits: offset within the frame remaining high order bits: page number i.e., index in page table ch. 4 34

35 why power of 2 example suppose: 8 byte, i.e., 2 3, pages 8 bit addresses logical address would be page 26, byte page number offset ch. 4 35

36 segmentation with paging break program up into segments segments broken into fixed sized pages Intel 386 ch. 4 36

37 segmentation with paging ch. 4 37

38 we re getting tired. what s the point of this again? each process has its own address space thinks it s the only process on machine MMU provides translation between process address space and physical space process cannot generate address not in its own space ch. 4 38

39 Chapter Outline 4.1 Protected Objects and Methods of Protection 4.2 Memory and Address Protection 4.3 Control of Access to General Objects 4.4 File Protection Mechanisms 4.5 User Authentication 4.6 Summary of Security for Users ch. 4 39

40 4.3 Control of Access to General Objects previous section: control of memory now: control of any kind of object examples: memory secondary storage hardware devices some data structure instructions passwords and user-authentication mechanism the protection mechanism itself ch. 4 40

41 goals in protecting objects check every access user permitted doesn t mean always permitted enforce least privilege grant access to minimum set of objects required to complete a task verify acceptable usage stack: push(), pop(), shouldn t be able to do anything else to stack ch. 4 41

42 directory not directory as in FS directory each user has a list (directory) of objects the user owns no user should be able to write to the directory for each file, directory contains list of permissions, e.g. R, W, X, and owner ch. 4 42

43 directory ch. 4 43

44 directory simple *but* lists can get very long what about shared libraries, programs? same item in many lists revoking permissions have to go through everyone s lists ch. 4 44

45 access control lists maintain a list per object, not user use wildcards (*) to grant permission to a group e.g. administrator-* ch. 4 45

46 unix file permissions ch. 4 46

47 access control matrix row for each user column for each protected object simple lookups but probably lots of empty spaces ch. 4 47

48 capabilities ticket implementation grant permission to a user allow user to perform particular op tickets transferable? should be unforgeable revokeable? ch. 4 48

49 kerberos later lots more on this in ch 7 ch. 4 49

50 procedure-oriented protection ch. 4 50

51 Chapter Outline 4.1 Protected Objects and Methods of Protection 4.2 Memory and Address Protection 4.3 Control of Access to General Objects 4.4 File Protection Mechanisms 4.5 User Authentication 4.6 Summary of Security for Users ch. 4 51

52 Chapter Outline 4.1 Protected Objects and Methods of Protection 4.2 Memory and Address Protection 4.3 Control of Access to General Objects 4.4 File Protection Mechanisms 4.5 User Authentication 4.6 Summary of Security for Users ch. 4 52

53 What s in a badge? Frank Coco flashed his lights told driver to pull over had to drive in front of other driver s car and put on brakes to force him to stop beat up the driver for not stopping left Frank wasn t a cop: to coworkers: he s Crazy Frank >1,000 such incidents in Chicago area in 3 years authentication problem ch. 4 53

54 Recover Lost Passwords Answer a secret question, e.g. mother s maiden name pet s name first car Good idea? ch. 4 54

55 Paris Hilton s Sidekick The Simple Life Password: tinkerbell ch. 4 55

56 Palin Yahoo! Reset password. No access to original . Questions: Birthday? February 11th, 1964 Zip code? Where d you meet spouse? Wasilla High ch. 4 56

57 Cracking Passwords recall password cracking lab cracking passwords already in use: offline crackers L0phtcrack John the Ripper online crackers, e.g.. http password crackers many, many others ounce of prevention check password strength when creating password but beware of rules that are too strict. Why? ch. 4 57

58 Password Authentication Instead of storing cleartext passwords Store passwords transformed through some one-way function, e.g. the hash of the password When user sends password take hash of the password, H(pass) check H(pass) == what s in password file ch. 4 58

59 Salt think about our password crack lab password cracker stores word lists why not store lists of precomputed hashes of words instead? create your own tables: to prevent against this, add randomness to password hash random data called salt ch. 4 59

60 Salted Password File userid salt hash jfiore hash(56129 jfiore's password) skippy hash(21592 skippy's password) lenny hash(55573 lenny's password) etc. ch. 4 60

61 authentication future graphical passwords? biometrics? two factor authentication? password + token password + something like SecureID password + biometrics ch. 4 61

62 authentication future graphical passwords? biometrics? two factor authentication? password + token password + something like SecureID password + biometrics ch. 4 62

63 biometrics Panacea or overkill? Privacy issues? Compromised back-end database? ch. 4 63

64 one-time passwords Lamport: chain of hashes h 1 =hash(secret) or hash(secret+salt) h 2 =hash(h 1 ) h n =hash(h n-1 ) at authentication time: first time, send h n next time, send h n-1, etc. when you reach 1, reset password ch. 4 64

65 web cookies for authentication e.g., Yahoo!, paid websites first page username, password sent over SSL each additional page session cookie ch. 4 65

66 Chapter Outline 4.1 Protected Objects and Methods of Protection 4.2 Memory and Address Protection 4.3 Control of Access to General Objects 4.4 File Protection Mechanisms 4.5 User Authentication 4.6 Summary of Security for Users ch. 4 66

67 Summary. Topics. memory protection file protection general object access control user authentication ch. 4 67