OS Security INTRODUCTION Toby Murray (with thanks to Gernot Heiser, from whom some of this material is borrowed) NICTA Copyright 2011 From imagination to impact 2 What is security? Computer Security • Different things to different people: • Protecting my interests that are under computer control from malign threats • Inherently subjective – Different people have different interests – Different people face different threats • Don’t expect one-size-fits-all solutions – Grandma doesn’t need an air gap – Windows alone is insufficient for protecting TOP SECRET classified data NICTA Copyright 2011 From imagination to impact 2 NICTA Copyright 2011 From imagination to impact 4 State of OS Security OS Security • Traditionally: • What is the role of the OS for security? – Has not kept pace with evolving user • Minimum: demographics – provide mechanisms to allow the • Focused on e.g. Defence and Enterprise construction of secure systems – Has not kept pace with evolving threats – that are capable of securely implementing the • Focused on protecting users from other users, not intended users’/administrators’ policies from the programs they run – while ensuring these mechanisms cannot be • Is getting better subverted – But is hindered because: • We don’t yet understand how to write secure code • OSes are getting larger and more complex NICTA Copyright 2011 From imagination to impact 5 NICTA Copyright 2011 From imagination to impact 6 Good security mechanisms Security Design Principles • Are widely applicable • Saltzer+Schroeder (SOSP ’73, CACM ’74) • Support general security principles – Economy of mechanism • Are easy to use correctly and securely – Fail-safe defaults • Do not hinder non-security priorities (e.g. – Complete mediation productivity, generativity) – Open design – Separation of privilege • Lend themselves to correct – Least privilege implementation and verification – Least common mechanism – Psychological acceptability NICTA Copyright 2011 From imagination to impact 7 NICTA Copyright 2011 From imagination to impact 8 Common OS Security Mechanisms Security Policies • Access Control Systems • Define what should be protected – control what each process can access – and from whom • Authentication Systems • Often in terms of common security goals: – confirm the identity on whose behalf a – Confidentiality process is running • X should not be learnt by Y • Logging – Integrity – for audit, detection, forensics and recovery • X should not be tampered with by Y • Filesystem Encryption – Availability • X should not be made unavailable to Z by Y • Credential Management • Automatic Updates NICTA Copyright 2011 From imagination to impact 9 NICTA Copyright 2011 From imagination to impact 10 Policy vs. Mechanism Assumptions • Policies accompany mechanisms: • All policies and mechanisms operate – access control policy under certain assumptions • who can access what? – e.g. TS cleared users can be trusted not to – authentication policy write TS data into the UNCLASS window • is password sufficient to authenticate TS access? • Problem: implicit or poorly understood • Policy often restricts the applicable assumptions mechanisms • Good assumptions: • One person’s policy is another’s – clearly identified mechanism – verifiable NICTA Copyright 2011 From imagination to impact 11 NICTA Copyright 2011 From imagination to impact 12 Risk Management Trust • Comes down to risk management • Systems always have trusted entites – At the heart of all security – whose misbehaviour can cause insecurity – Assumptions: risks we are willing to tolerate – hardware, OS, sysadmin ... • Other risks: • Trusted Computing Base (TCB): – we mitigate (using security mechanisms) – the set of all such entities – or transfer (e.g. by buying insurance) • Secure systems require trustworthy • Security policy should distinguish which is TCBs appropriate for each risk – achieved through assurance and verification – Based on a thorough risk assessment – shows that the TCB is unlikely to misbehave – why the TCB should be as small as possible NICTA Copyright 2011 From imagination to impact 13 NICTA Copyright 2011 From imagination to impact 14 Assurance and Formal Verification Covert Channels • Assurance: • Information flow not controlled by security – systematic evaluation and testing mechanism • Formal verification: – confidentiality requires absence of all such – mathematical proof • Covert Storage Channel: • Together trying to establish correctness of: – attribute of shared resource used as channel – the design of the mechanisms – controllable by access control – and their implementation • Covert Timing Channel: • Certification: establishes that the – temporal order of shared resource accesses assurance or verification was done right – outside of access control system – much more difficult to control and analyse NICTA Copyright 2011 From imagination to impact 15 NICTA Copyright 2011 From imagination to impact 16 Covert Timing Channels Summary: Introduction • Created by shared resource whose timing- • Security is very subjective related behaviour can be monitored • OS security: – network bandwidth, CPU load ... – provide good security mechanisms • Requires access to a time source – that support users’ policies – anything that allows processes to synchronise • Security depends on establishing • Critical issue is channel bandwidth trustworthiness of trusted entities – low bandwidth limits damage – TCB: set of all such entities • why DRM doesn’t ignores low bandwidth channels • should be as small as possible – beware of amplification – Main approaches: assurance and verification • e.g. leaking passwords, encryption keys etc. • The OS is necessarily part of the TCB NICTA Copyright 2011 From imagination to impact 17 NICTA Copyright 2011 From imagination to impact 18 Access Control • who can access what in which ways – the “who” are called subjects • e.g. users, processes etc. – the “what” are called objects ACCESS CONTROL PRINCIPLES • e.g. individual files, sockets, processes etc. • includes all subjects – the “ways” are called permissions • e.g. read, write, execute etc. • are usually specific to each kind of object • include those meta-permissions that allow modification of the protection state – e.g. own NICTA Copyright 2011 From imagination to impact 19 NICTA Copyright 2011 From imagination to impact 20 AC Mechanisms and Policies Protection State • AC Policy • Access control matrix defines the – Specifies allowed accesses protection state at any instant in time – And how these can change over time • AC Mechanism Obj1 Obj2 Obj3 Subj2 – Implements the policy Subj1 R RW send • Certain mechanisms lend themselves to certain kinds of policies Subj2 RX control – Certain policies cannot be expressed using certain mechanisms RWX Subj3 RW recv own NICTA Copyright 2011 From imagination to impact 21 NICTA Copyright 2011 From imagination to impact 22 Storing Protection State Access Control Lists (ACLs) • Not usually as access control matrix • Subjects usually aggregated Obj1 – too sparse, inefficient into classes • Two obvious choices: – e.g. UNIX: owner, group, Subj1 R – store individual columns with each object everyone • Meta-permissions (e.g. own) • defines the subjects that can access each object Subj2 • each such column is called the object’s access – control class membership control list – allow modifying the ACL – store individual rows with each subject Subj3 RW • Implemented in almost all • defines the objects each subject can access commercial OSes • each such is called the subject’s capability list NICTA Copyright 2011 From imagination to impact 23 NICTA Copyright 2011 From imagination to impact 24 Capabilities Capabilities: Implementations • A capability is a capability list element • Capabilities must be unforgeable • On conventional hardware, either: Obj1 Obj2 Obj3 Subj2 – Stored as ordinary user-level data, but Subj1 unguessable due to sparseness R RW send • like a password or an encryption key – Stored separately (in-kernel), referred to by – Names an object to which the capability refers user programs by index/address – Confers permissions over that object • like UNIX file descriptors • Less common in commercial systems • Sparse capabilities can be leaked more – More common in research though easily, but are easier to revoke – The only solution for most distributed systems NICTA Copyright 2011 From imagination to impact 25 NICTA Copyright 2011 From imagination to impact 26 ACLs and Capabilities: Duals? Duals?: Naming and Namespaces • In theory: • ACLs: – Dual representations of access control matrix – objects referenced by name • Practical differences: • e.g. open(“/etc/passwd”,O_RDONLY) – Naming and namespaces – require a subject (class) namespace • Confused Deputies • e.g. UNIX users and groups – Evolution of protection state • Capabilities: – Forking – objects referenced by capability – Auditing of protection state • object namespace still required though – no subject namespace required NICTA Copyright 2011 From imagination to impact 27 NICTA Copyright 2011 From imagination to impact 28 Duals?: Confused Deputies Duals?: Evolution of Protection State • ACLs: separation of object naming and • ACLs: permission can lead to confused deputies – Protection state changes by modifying ACLs – Capabilities are both names and permissions • Requires certain meta-permissions on the ACL • You can’t name something without having • Capabilities: permission to it – Protection state changes by delegating and revoking capabilities X RW • Right to delegate controlled by certain capabilities