Security and Privacy 12A. Operating Systems Security Operating - PDF document

5/18/2016 Security and Privacy 12A. Operating Systems Security Operating Systems Principles 12B. Authentication 12C. Authorization Security and Privacy 12D. Trust 12E. At-Rest Encryption Mark Kampe (markk@cs.ucla.edu) Security and Privacy 2 Operating System Security – Goals Security Concepts • privacy • principals – (e.g. users) own, control, and use protected objects – keep other people from seeing your private data • agents • integrity – (e.g. programs) act on behalf of principals – keep other people from changing your protected data • authentication • trust – confirming the identity of requesting principal – programs you run cannot compromise your data – confirming the integrity of a request • credentials – remote parties are who they claim to be – information that confirms identity of requesting principal – binding commitments and authoritative records • authorization • controlled sharing – determining if a particular request is allowed – you can grant other people access to your data • mediated access – but they can only access it in ways you specify – agents must access objects through control points Security and Privacy 3 Security and Privacy 4 Why Security is Difficult Security – Key Elements • reliable authentication • complexity of our software and systems – we must be sure who is requesting every operation – millions of lines of code, thousands of developers – we must prevent masquerading of people/processes – rich and powerful protocols and APIs • trusted policy data – numerous interactions with other software – policy data accurately describes desired access rules – constantly changing features and technology • reliable enforcement mechanisms – absence of comprehensive validation tools – all operations on protected objects must be checked • determined and persistent adversaries – it must be impossible to circumvent these checks • audit trails – commercial information theft/black-mail – reliable records of who did what, when – national security, sabotage Security and Privacy 5 Security and Privacy 6 1

5/18/2016 External (user) Authentication Cryptographic Hash Functions • authentication done by trusted "login" agent • “one-way encryption” function: H(M) – typically based on passwords and/or identity tokens – H(M) is much shorter than M – movement towards biometric authentication – it is inexpensive to compute H(M) • ensuring secure passwords – it is infeasible to compute M(H) – they must not be guess-able or brute-force-able – it is infeasible to find an M’: H(M’) = H(M) – they must not be steal-able • uses • ensuring secure authentication dialogs – protection from crackers: humanity checkers – store passwords as H(pw) – protection from snoopers: challenge/response • verify by testing H(entered) = stored H(pw) – protection from fraudulent servers: certificates – secure integrity assurance • evolving encryption technology can assist us here • deliver H(msg) over a separate channel Security and Privacy 7 Security and Privacy 8 challenge/response authentication Internal (process) Authentication • untrusted authentication • OS associates credentials with each process – client/server distrust one-another & connecting wire – stored, within the OS, in the process descriptor – both claim to know the secret password – automatically inherited by all child processes – neither is willing to send it over the network – identify the agent on whose behalf requests are made • client and server agree on a complex function • they are the basis for access control decisions – response = F(challenge,password) – F may be well known, but is very difficult to invert – they are consulted when accessing protected data • server issues random challenge string to client – they are reported in audit logs of who did what – server & client both compute F(challenge,password) • they are established by a privileged system call – client sends response to server, server validates it – only a small number of trusted programs can use it • man-in-middle cannot snoop, spoof, or replay – they must be carefully written, reviewed, and tested Security and Privacy 9 Security and Privacy 10 UNIX Credential Establishment The Authorization Matrix Principal Object 1 Object 2 Object 3 … virtual login encrypted user terminal agent passwords registry User 1 Read/write Read/write Read-only name, password User 2 read Read/write lookup(name) encrypted password User 3 Read-only Read/write verify lookup(name) UID, GID • A[ principal,object ] = principal’s access to object setGid/setUid – row list of represents principal’s capabilities exec(shell) – column represents objects’s access control list shell prompt Security and Privacy 11 Security and Privacy 12 2

5/18/2016 (The Authorization Matrix) Capabilities and ACLs • provides the answer to access control questions • Capabilities – per agent access control – can subject S perform operation O on object X? – record, for each principal, what it can access – this can be abstractly thought of as a matrix A[S,X] – each granted access is called a "capability" – a capability is required to access any system object • there are two obvious real representations • Access Control Lists – per object access control – what things a subject is allowed to do (capabilities) – who can access an object (access control lists) – record, for each object, which principals have access – each protected object has an Access Control List • updating this matrix is a critical operation – OS consults ACL when granting access to any object – errors in the data will result in incorrect decisions • Either must be protected & enforced by the OS – updating this data is, itself a controlled operation (e.g. is S allowed to change access control data for X?) Security and Privacy 13 Security and Privacy 14 Access Control Lists vs. Capabilities Unix files – access control lists • Subject Credentials: • Access Control Lists – user and group ID, established by password login – short to store and easy to administer • Supported operations: • Capabilities make very convenient handles – read, write, execute, chown, chgrp, chmod – if you have the capability, you can do the operation • Representation of ACL information: – without one, you can't even ask for operations – rules (owner:rwx, group:rwx, others:rwx) • many operating systems actually use both – owner privileges apply to the file's owner – ACLs describe what accesses are allowed – group privileges apply to the file's owning group – when access is granted, a Capability is issued – others privileges apply to all other users – capability is used as handle for subsequent operations – only owner can chown/chgrp/chmod Security and Privacy 15 Security and Privacy 16 Unix File Access – example Unix files also have capabilities • if a process wants to read or write a file given a file with: – it must open the file, requesting read or write access user ID: 100 – open will check permissions before granting access group ID: 15 – if operation permitted, OS returns a file descriptor - x - - file protection: r w x r r • the user file descriptor is a capability UID/GID read write execute chmod – it is an unforgable token conferring access to the file yes yes yes yes 100/001 yes no yes no 001/015 – it confers a specific access (r/w) to a specific file yes no no no 001/001 – a required argument to the read/write system calls yes yes yes yes 000/###* – without a file descriptor reads/writes are impossible * In UNIX, a process with UID=0 (super user) can do anything Security and Privacy 17 Security and Privacy 18 3