security and privacy why security is difficult
play

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

5/18/2018 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


  1. 5/18/2018 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 and Access Control – 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 and Privacy 1 Security and Privacy 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 and Privacy 3 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 and Privacy 6 1

  2. 5/18/2018 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 and Privacy 7 Security and Privacy 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 and Privacy 9 Security and Privacy 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 and Privacy 11 Security and Privacy 12 2

  3. 5/18/2018 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 and Privacy 13 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 and Privacy 15 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 and Privacy 17 Security and Privacy 18 3

Recommend


More recommend