Security and Privacy Why Security is Difficult 12A. Operating - PDF document

5/24/2017 Security and Privacy Why Security is Difficult 12A. Operating Systems and Security • complexity of our software and systems 12B. Authentication – millions of lines of code, thousands of developers – rich and powerful protocols and APIs 12C. Authorization – numerous interactions with other software 12D. Trust – constantly changing features and technology 13G. Encryption – absence of comprehensive validation tools 12E. At-Rest Encryption • determined and persistent adversaries – commercial information theft/black-mail – national security, sabotage Security 1 Security 2 Common Terms used in Security Trust • security • An extremely important security concept – policies regarding who can access what, when and how • You do certain things for those you trust • protection • You don’t do them for those you don’t – mechanisms that implement/enforce security policies • attacker • Seems simple, but . . . – an actor who seeks to bypass access control policies – How do you express trust? • vulnerability – a protection weakness that enables a potential attack – Why do you trust something? • exploit – How can you be sure who you’re dealing with? – a successful use of a vulnerability to bypass protection – What if trust is situational? – also refers to the code or methodology that was used • trust – What if trust changes? – confidence in the reliability (invulnerability) of a mechanism – confidence about the future behavior of an actor Security 3 Security 4 Trust and the Operating System Operating System Security – Goals • privacy • We have to trust our operating system – keep other people from seeing your private data – it controls the CPU and memory • integrity – it controls how your processes are handled – keep other people from changing your protected data – it controls all the I/O devices • trust – programs you run cannot compromise your data • The OS is the foundation for all software – remote parties are who they claim to be – all higher level security is based on a reliable OS – binding commitments and authoritative records • If the OS is out to get you, you are gotten • controlled sharing – you can grant other people access to your data – which makes compromising an OS a big deal – but they can only access it in ways you specify – which makes securing the OS a big deal Security 5 Security 6 1

5/24/2017 Terms w/very special meanings Security – Key Elements • principals • reliable authentication – (e.g. users) own, control, and use protected objects – we must be sure who is requesting every operation • agents – we must prevent masquerading of people/processes – (e.g. programs) act on behalf of principals • trusted policy data • authentication – confirming the identity of requesting principal – policy data accurately describes desired access rules – confirming the integrity of a request • reliable enforcement mechanisms • credentials – all operations on protected objects must be checked – information that confirms identity of requesting principal • authorization – it must be impossible to circumvent these checks – determining if a particular request is allowed • audit trails • mediated access – reliable records of who did what, when – agents must access objects through control points Security 7 Security 8 Authentication Internal (process) Authentication • OS associates credentials with each process • security policy says who is allowed to do what – stored, within the OS, in the process descriptor • enforcement presumes we know who is asking – automatically inherited by all child processes • Authentication problems – identify the agent on whose behalf requests are made – how to authenticate an actor’s claimed identity? • they are the basis for access control decisions – how can we trust authentication secrets? – they are consulted when accessing protected data – how can we trust authentication dialogs? – they are reported in audit logs of who did what • how do we ensure their correctness – commands are coming from the indicated principal – not from some would-be attacker/impostor Security 9 Security 10 UNIX Credential Establishment External (user) Authentication • authentication done by trusted "login" agent virtual login encrypted user terminal – typically based on passwords and/or identity tokens agent passwords registry – movement towards biometric authentication name, password lookup(name) • ensuring secure passwords encrypted password – they must not be guess-able or brute-force-able verify – they must not be steal-able lookup(name) • ensuring secure authentication dialogs UID, GID – protection from crackers: humanity checkers setGid/setUid – protection from snoopers: challenge/response exec(shell) – protection from fraudulent servers: certificates • evolving encryption technology can assist us here shell prompt Security 11 Security 12 2

5/24/2017 Cryptographic Hash Functions Secure Passwords • one-way hashes protect stored passwords • “one-way encryption” function: H(M) • unless they are easily guessed, because – H(M) is much shorter than M – it is inexpensive to compute H(M) … they are short enough to brute-force … they are obvious enough to guess – it is infeasible to compute M(H) – it is infeasible to find an M’: H(M’) = H(M) … they are words in a dictionary … they have been shared with others • uses … they were written where others found them – store passwords as H(pw) … they are seldom changed • verify by testing H(entered) = stored H(pw) – secure integrity assurance • password guidelines try to prevent these • deliver H(msg) over a separate channel Security 13 Security 14 challenge/response authentication Goals for Access Control • untrusted authentication • Complete mediation – client/server distrust one-another & connecting wire – all protected object access is subject to control – both claim to know the secret password • Cost and usability – neither is willing to send it over the network – mediation does not impose performance penalties • client and server agree on a complex function – response = F(challenge,password) – mediation does not greatly complicate use – F may be well known, but is very difficult to invert • Useful in a networked environment • server issues random challenge string to client – where all resources not controlled by a single OS – server & client both compute F(challenge,password) • Scalability – client sends response to server, server validates it • man-in-middle cannot snoop, spoof, or replay – large numbers of computers, agents, and objects Security 15 Security 16 Complete Mediation? Access Mediation • protected resources must be inaccessible • Per-Operation Mediation (e.g. file) – hardware protection must be used to ensure this – all operations are via requests – only the OS can make them accessible to a process – we can check access on every operation • to get access, issue request to resource manager – revocation is simple (cancel the capability) – resource manager consults access control policy data – access is relatively expensive (system call/request) • access may be granted directly • Open-Time Mediation (e.g. shared segment) – resource manager maps resource into process – one-time access check at open time • access may be granted indirectly – if permitted, resources is mapped in to process – resource manager returns a “capability” to process – subsequent access is direct (very efficient) – capability can be used in subsequent requests – revocation may be difficult or awkward Security 17 Security 18 3