Protection in General-purpose Operating Systems

Transcription

1 Protection in Generalpurpose Operating Systems David Morgan Evolution of operating systems serial processing simple batch systems multiprogrammed batch systems timesharing systems

2 Serial processing no operating system programmers interacted directly with hardware console consisting of display lights and toggle switches Front panel display lights and toggle switches

3 Serial processing poor utilization user time reserved by hardcopy signup sheet job duration sometimes shorter than scheduled cpu unutilized till next reservation Simple batch systems processor utilization paramount due to extreme expense monitor program introduced user no longer can access hardware job deck (punched cards) submitted to operator multiple jobs placed on input device program branches back to monitor on termination

4 Memory layout with resident monitor monitor controls the sequence of events resident monitor is software always in memory monitor reads in job and gives control job returns control to monitor Simple batch system overhead processor time alternates between execution of user programs and execution of the monitor sacrifices some main memory is now given over to the monitor some processor time is consumed by the monitor despite overhead, the simple batch system improves utilization of the computer

5 CTSS compatible time sharing system developed at MIT by a group known as Project MAC ran on a computer with 32,000 36bit words of main memory, with the resident monitor consuming 5000 of that to simplify both the monitor and memory management a program was always loaded to start at the location of the 5000th word CTSS compatible time sharing system system clock generates an interrupt every 0.2s OS regained control and could assign processor to another user at regular time intervals the current user would be preempted and another user loaded in old user programs and data were written out to disk

6 CTSS operation Job sizes words jobs loaded in order 1, 2, 3, 1, 4, 2 The role of hardware modes of operation user mode user programs execute in user mode protected memory areas cannot be accessed privileged instructions may not be executed kernel mode monitor/os executes in kernel mode protected memory areas may be accessed privileged instructions may be executed

7 Hardware for operating systems early OSs ran on particular hardware platforms commercial: IBM MVS, DEC VAX, Burroughs and GE research: KSOS, PSOS, KVM, Multics, SCOMP could take entire advantage of hardware s protection mechanisms later OSs are portable across platforms Windows, unix/linux cannot take full advantage, only of common denominator protection mechanisms Means of separation physical separation A and B use different computers or peripherals temporal separation A and B use them at different times logical separation A and B are held apart in separate domains by an OS cryptographic separation A and B encrypt their data from one another

8 Sharing (in tension with separation) do not protect when procedures run at separate times isolate wall processes off from each other share all or share nothing owner publically shares wholly or not at all share via access limitation evaluate each access to an object according to subject share by capabilities evaluate each access by subject according to object limit use of an object once object is accessed, what process can do with it Demo linux shared memory backing off process separation with IPC several interprocess communication means shared memory pipes semaphores mutexes demonsration of shared memory

9 Writing to share memory segment eading from shared memory segment

10 Memory protection fence base/bounds registers tagged architecture segmentation paging relocation Fence

11 Variable fence register Base/bounds registers

12 Base/bounds registers Tagged architecture extra bits in every address may represent what kind of value is held here (instruction vs data) what access rights apply to that value check upon every access

13 Logical addresses Segmentation program can be divided into segments variable length maximum length 2part addresses segment number or name an offset

14 Segmentation equivalent to multiple base/bounds registers many pieces, potentially different access rights Segmentation usually visible (unlike paging) organizational convenience for subdividing process memory into pieces code can go here, data there, stack yonder segments can be further subdivided

15 Segmentation tables a perprocess table giving segment names and offsets a single OS table giving segment names and their true addresses Segmentation namebased

16 Segmentation unequal segment sizes no formula for logicaltophysical address translation (unlike paging) translation steps extract segment number as leftmost n bits of logical address use the segment number to index into the process segment table to find starting physical address of the segment compare offset, from rightmost m bits, to segment s length (if greater, error) physical address is sum of segment starting address plus offset Address translation w/segmentation

17 Address formation w/segmentation Segmentation namebased

18 Address hiding advantages segment is relocatable segment is swapoutable OS address translation step can include an access control decision Address hiding advantages address references are protection checked different protection can be accorded to different kinds of data multiple users can share access to a segment, with different access rights users cannot generate addresses or access unpermitted segments

19 Paging divide processes into equal fixedsize pieces partition memory into sections of that same size Page table, per each process maps inmemory pages to the frames that contain them address formation/determination must go through the table processor produces physical address from program s logical address plus the table

20 Pageto toframe assignments Process sizes A 4 pages B 3 pages C 4 pages D 5 pages processes loaded in alphabetical order, B terminates after C loaded esultant page tables D s pages distributed noncontiguously

21 Address formation with paging Address translation with paging

22 Paged segmented addressing Table entry formats Potential opportunity to label a segment with general security parameters

23 Virtual memory paging load can be partial pages are in disk store Contiguity/completeness of loading

24 elocation elocation of programs generally calls for a few internal adjustments. Parts of a program (certain of its instructions) typically reference addresses within the program. Obviously, if the program as a whole gets shifted from one place in memory to another (i.e., relocated), every portion of the program moves with it. So any part of the program that accounts for the address of the program, must account for the change of address of the program. General object access control directory one list for each subject, giving objects here are the files this user can access acl one list for each object, giving subjects here are the users that can access this file acm access control matrix expression of both

25 persubject directories subjects a directory of objects for each perobject access control lists objects a list of subjects for each

26 linux (ext filesystem) ACLs ACL exists for this file student can t read grades, teacher can make special changes, via ACL grades ACL student can now read grades, teacher no longer can (ACL overrides) Access control matrix BIBLIOG TEMP F HELP.TXT C_COMP LINKE SYS_CL OCK PINTE user A OW OW OW X X W user B X X W user S W X X W user T X X W Sys_mgr W OX OX OW O User_svcs O X X W

27 ACM cols=acls, rows=dirs BIBLIOG s acl user A s directory BIBLIOG TEMP F HELP.TXT C_COMP LINKE SYS_CL OCK PINTE user A OW OW OW X X W user B X X W user S W X X W user T X X W Sys_mgr W OX OX OW O User_svcs O X X W A capability an object id together with rights to it acm row is a list of subject s capabilities x can to this with a, that with b, etc other examples keys on somebody s physical keyring a concert ticket the set of groups of which a linux user is a member the conceptual capability list is not the group list it is the list of objects in the filesystem having those groups, each together with its group permissions e.g. somefile r is one of the capabilities in the capability list user david belongs to inf520, cs530, teachers

28 A capability an unforgeable token that gives the possessor certain rights to an object making the ticket unforgeable hardware tags protected address space cryptography protected address space implementation as example capability list retained in kernel memory process only gets indices into table can only reference capabilities that exist under kernel escrow, not directly linux process descriptor process descriptor table could add a capability list to all this a descriptor, for a single process; contains or points to that process s attributes identifiers, state, resources my process id number user account associated with me id number of my parent process id numbers of my children my state readiness to run run priority CPU s state flags register values files I hold open memory locations I occupy

29 Process domain / name space collection of all objects accessible to process varies dynamically Kerberos Starting point: parties want to talk a client a server but confidentially don t forget! our wishful hope: if only they had a common key!

30 What if there were a key fairy? fairy performs a double key transmittal a client a server Fairy would fly away Parties could talk confident(ial)ly thereafter a client a server These keys would be disposable, just for the session or just for today. (If there is such a thing as the client key or the server key that persist, these aren t it.) After today: Tomorrow?? : trash the keys ask for some new ones (they re free!)

31 Generalize the idea to a whole community clients clients could share keys with servers clienta clientb clientc servers server types mail time login/shell web clienta can secure 1) mail traffic 2) web traffic blue, red pairs respectively clientb can secure 1) mail traffic 2) login traffic purple, green pairs clientc can secure 1) file transfer traffic Yellow pair file transfer Actually there is no a key fairy. There s Kerberos. kerberos a client a server

32 Here client, have this pair of keys for you and server. Keep one for yourself and give the other to him. How the dualhandoff really works kerberos step 1 a client a server How the dualhandoff really works step 2 Here server, have this key and use it for cryption when we talk from now on kerberos a client a server

33 kerberos kerberos gets out of the way parties talk confident(ial)ly thereafter a client a server User authentication passwords biometrics hardware tokens

34 Password guessing: easy or hard? an alphabet is a set of symbols how many words of a certain length can you compose from an alphabet? depends on the number of symbols in the alphabet the particular wordlength How many words are there? 26letter alphabet, wordlength 3: 26 3 = letter alphabet, wordlength 3: 52 3 = 140,608 double alphabet length yields 8 times as many words 26letter alphabet, wordlength 6: 26 6 = 308,915,776 double word length yields times as many words 52letter alphabet, wordlength 6: 52 6 = 19,770,609,660 a fish is in a pond harder to catch in a bigger pond

35 Password strength determinants the number of possible characters it contains its length the randomness of character selection a 3 rd criterion!! humandependent! (arguably, the most important factor these days) Human factor discovery From passwords captured in large volume in recent publicized leaks, more commonly than expected, people chose 9character passwords whose first 5 characters are letters, last 4 are numbers, first character is sometimes capitalized, others are not. andom: any any any any any any any any any Observed: wordspace 96^9 = 7 * 10^17 1 million times bigger 1 million times smaller alpha lower lower lower lower num num num num wordspace 52*26*26*26*26*10*10*10*10 = 2 * 10^11

36 Passwords hashed, stored in /etc/shadow this is what exfiltrator has to work with MD5 SHA512 Bruteforce attack tries every character combination until it finds the password timeconsuming in proportion to password space will always find the password, given time cf. The Library of Babel by Jose Luis Borges

37 Bruteforce attack time estimator PAM* architecture 1 PAM 2 /etc/pam.d 4 PAMaware applications (e.g., /bin/login) /lib/security 3 configuration files *Pluggable Authentication Modules PAM modules

38 Default directories and files / /etc/pam.d /lib/security /etc/security /usr/share/doc/pamxx individual config files for each app the PAM modules, as shared library files modulespecific config files for modules that need them PAM documentation Operation sequence app calls PAM (1) PAM reads app s PAM config file (2) PAM calls PAM modules as listed in the file (3) each succeeds or fails independently PAM itself succeeds or fails, depending on the modules outcomes returns its overall outcome to app (4) app proceeds (if success) or terminates (if failure) the module that evaluates passwords can be supplemented or replaced by one(s) that evaluate biometric or hardtoken input instead

39 Example: hardware authentication tokens Yubico YubiKey SA SecureID Pressing yubikey, in Notepad yubikey is a USB keyboard device it types 44 letters whenever pressed right 32 letters left 12 letters onetime password, generated this time invariant public ID of this yubikey, generated every time

40 Good play, bad replay from pressing keyboard from pressing yubikey ykclient utility queries validation server with key from command history recall buffer 2 seconds later (onetime key, used 2 nd time, is stale) play: red client to server blue server to client replay:

41 PAM for sshd: involving yubikey in ssh logins sshd 1 PAM 2 /etc/pam.d 4 a PAMaware application 3 sshd pam_yubico.so PAM module for yubikey specifies pam_yubico.so configuration file for sshd program Configuration details corresponds this machine s david account to the particular white yubikey I bought recently, so a valid key from that yubikey device is good for admission to this account

42 yubikey pressed here client 1 yubikey types onetime key to client PuTTY 2 client PuTTY sends key to server sshd 3 sshd passes key to pam_yubico.so 4 pam_yubico.so ships it to api.yubico.com for validation ssh login by yubikey i n c r e a s i n g t i m e s e r v e r per yubico authentication server 5 api.yubico.com returns OK to pam_yubico.so 6 pam_yubico.so returns OK to sshd 7 sshd launches shell client Construction of output cccccccvrjbc = unique public ID s t a t i c a l l y s t o r e d B3D6 = unique secret ID = unique symmetric key (for AES) d y n a m i c a l l y g e n e r a t e d cccccccvrjbc encrypt cccccccvrjbc c o n c a t e n a t e tjjneccdnuerugkclcvenbilblgkdiie output cccccccvrjbctjjneccdnuerugkclcvenbilblgkdiie

43 Authentication processing application server validation request authentication server validation response app request app response public ID serial no. secret ID d a t a b a s e symmetric key last sequence number etc application client cccccccvrjbc B3D6 179