Outline and Operating u Access Control u Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks u OS Policies u Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • • • Windows 2000 – File system, Setuid certification • Windows u Some Limitations – File system, Tokens, EFS • Information flow • SE • Covert channels – Role-based – Domain type enforcement

Access control Access control matrix [Lampson] uCommon Assumption • System knows who the user is File 1 File 2 File 3 … File n – User has entered a name and password, or other info • Access requests pass through gatekeeper User 1 read write - - read – Global property; OS must be designed so that this is true User 2 write write write - - Reference monitor User 3 - - - read read User … ? Resource User m read write read write read

Decide whether user can apply operation to resource

Two implementation concepts Capabilities uAccess control list (ACL) File 1 File 2 … uOperating system concept • Store column of matrix User 1 read write - • “… of the future and always will be …” with the resource User 2 write write - uExamples uCapability User 3 - - read • Dennis and van Horn, MIT PDP-1 Timesharing • Allow user to hold a … • Hydra, StarOS, Intel iAPX 432, Amoeba, Eros, … “ticket” for each resource User m read write write • Roughly: store row of matrix with the user uReference • Henry Levy, Capability-based Computer Systems http://www.cs.washington.edu/homes/levy/capabook/ Access control lists are widely used, often with groups Some aspects of capability concept are used in Kerberos, …

1 Roles (also called Groups) Groups for resources, rights uRole = set of users uPermission = áright, resourceñ • Administrator, PowerUser, User, Guest uGroup related resources • Assign permissions to roles; each user gets permission uHierarchy for rights or resources uRole hierarchy • If user has right r, and r>s, then user has right s • Partial order of roles Administrator • If user has read access to directory, user has read • Each role gets access to every file in directory PowerUser permissions of roles below • List only new permissions User uBig problem in access control given to each role • Complex mechanisms require complex input Guest • Difficult to configure and maintain • Roles, other organizing ideas try to simplify problem

Multi-level Security Concepts Military security policy uMilitary security policy uSensitivity levels uCompartments – Classification involves sensitivity levels, compartments – Do not let classified information leak to unclassified files Satellite data uGroup individuals and resources Afghanistan • Use some form of hierarchy to organize policy Middle East Israel uOther concepts Top Secret • Separation of duty Secret • Chinese Wall Policy Confidential Restricted Unclassified

Military security policy Commercial version uClassification of personnel and data Product specifications • Class = árank, compartmentñ Discontinued uDominance relation In production OEM • D1 £ D2 iff rank1 £ rank2 Internal and compartment1 Í compartment2 Proprietary • Example: áRestricted, Israelñ £ áSecret, Middle Eastñ Public uApplies to • Subjects – users or processes • Objects – documents or resources

2 Bell-LaPadula Confidentiality Model Picture: Confidentiality uWhen is it OK to release information? Read below, write above Read above, write below uTwo Properties (with silly names) • Simple security property Proprietary Proprietary – A subject S may read object O only if C(O) £ C(S) • *-Property – A subject S with read access to O may write object P only if C(O) £ C(P) S S uIn words, • You may only read below your classification and Public Public only write above your classification

Biba Integrity Model Picture: Integrity uRules that preserve integrity of information Read above, write below Read below, write above uTwo Properties (with silly names) • Simple integrity property Proprietary Proprietary – A subject S may write object O only if C(S) ³ C(O) (Only trust S to modify O if S has higher rank …) • *-Property – A subject S with read access to O may write object P only S S if C(O) ³ C(P) (Only move info from O to P if O is more trusted than P) uIn words, Public Public • You may only write below your classification and only read above your classification

Problem: Models are contradictory Other policy concepts uBell-LaPadula Confidentiality uSeparation of duty • Read down, write up • If amount is over $10,000, check is only valid if uBiba Integrity signed by two authorized people • Read up, write down • Two people must be different • Policy involves role membership and ¹ uWant both confidentiality and integrity • Only way to satisfy both models is only allow read uChinese Wall Policy and write at same classification • Lawyers L1, L2 in Firm F are experts in banking • If bank B1 sues bank B2, – L1 and L2 can each work for either B1 or B2 In reality: Bell-LaPadula used more than Biba model – No lawyer can work for opposite sides in any case Example: Common Criteria • Permission depends on use of other permissions

3 Example OS Mechanisms Multics uMultics uOperating System uUnix • Designed 1964-1967 uWindows – MIT Project MAC, Bell Labs, GE • At peak, ~100 Multics sites (briefly) uSE Linux • Last system, Canadian Department of Defense, Nova Scotia, shut down October, 2000 u Extensive Security Mechanisms • Influenced many subsequent systems

http://www.multicians.org/security.html

Multics time period Multics Innovations uTimesharing was new concept uSegmented, Virtual memory • Serve Boston area with one 386-based PC • Hardware translates virtual address to real address uHigh-level language implementation • Written in PL/1, only small part in assembly lang uShared memory multiprocessor • Multiple CPUs share same physical memory uRelational • Multics Relational Data Store (MRDS) in 1978 uSecurity • Designed to be secure from the beginning • First B2 security rating (1980s), only one for years

Multics Access Model Unix file security uRing structure uEach file has owner and group • A ring is a domain in which a process executes uPermissions set by owner setid • Numbered 0, 1, 2, … ; Kernel is ring 0 • Read, write, execute - rwx rwx rwx • Graduated privileges • Owner, group, other – Processes at ring i have privileges of every ring j > i • Represented by vector of ownr grp othr uSegments four octal values • Each data area or procedure is called a segment uOnly owner, root can change permissions • Segment protection áb1, b2, b3ñ with b1 £ b2 £ b3 • This privilege cannot be delegated or shared – Process/data can be accessed from rings b1 … b2 – A process from rings b2 … b3 can only call segment at uSetid bits – Discuss in a few slides restricted entry points

4 Question Effective user id (EUID)

uOwner can have fewer privileges than other uEach process has three Ids (+ more under Linux) • What happens? • Real user ID (RUID) – User gets access? – same as the user ID of parent (unless changed) – User does not? – used to determine which user started the process • Effective user ID (EUID) – from set user ID bit on the file being executed, or sys call uPrioritized resolution of differences – determines the permissions for process if user = owner then owner permission • file access and port binding else if user in group then group permission • Saved user ID (SUID) else other permission – So previous EUID can be restored uReal group ID, effective group ID, used similarly

Process Operations and IDs Setid bits on executable Unix file

uRoot uThree setid bits • ID=0 for superuser root; can access any file • Setuid – set EUID of process to ID of file owner uFork and Exec • Setgid – set EGID of process to GID of file • Inherit three IDs, except exec of file with setuid bit • Sticky – Off: if user has write permission on directory, can rename uSetuid system calls or remove files, even if not owner • seteuid(newid) can set EUID to – On: only file owner, directory owner, and root can – Real ID or saved ID, regardless of current EUID rename or remove file in the directory – Any ID, if EUID=0

uDetails are actually more complicated • Several different calls: setuid, seteuid, setreuid

Example Compare to stack inspection

Owner 18 RUID 25 SetUID uCareful with Setuid ! • Can do anything that A 1 …; program owner of file is …; allowed to do B 1 exec( ); • Be sure not to Owner 18 -rw-r--r-- – Take action for …; RUID 25 untrusted user C 1 file read/write …; EUID 18 – Return secret data to i=getruid() untrusted user Owner 25 setuid(i); -rw-r--r-- …; read/write RUID 25 Note: anything possible if root; no middle file …; EUID 25 ground between user and root

5 Setuid programming Unix summary uWe talked about this before … uWe’re all very used to this … uBe Careful! • So probably seems pretty good • Root can do anything; don’ t get tricked • We overlook ways it might be better • Principle of least privilege – change EUID when uGood things root privileges no longer needed • Some protection from most users uSetuid scripts • Flexible enough to make things possible • This is a bad idea uMain bad thing • Historically, race conditions • Too tempting to use root privileges – Begin executing setuid program; change contents of • No way to assume some root privileges without all program before it loads and is executed root privileges

Access control in Windows (NTFS) Sample permission options uBasic functionality similar to Unix uSID • Specify access for groups and users • Identity (replaces UID) – Read, modify, change owner, delete – SID revision number uSome additional concepts – 48-bit authority value – variable number of • Tokens Relative Identifiers • Security attributes (RIDs), for uniqueness • Users, groups, uGenerally computers, domains, domain members all • More flexibility than Unix have SIDs – Can define new permissions – Can give some but not all administrator privileges

Permission Inheritance Tokens uStatic permission inheritance (Win NT) uSecurity Reference Monitor • Initially, subfolders inherit permissions of folder • uses tokens to identify the security context of a • Folder, subfolder changed independently process or • Replace Permissions on Subdirectories command uSecurity context – Eliminates any differences in permissions • privileges, accounts, and groups associated with uDynamic permission inheritance (Win 2000) the process or thread • Child inherits parent permission, remains linked uImpersonation token • Parent changes are inherited, except explicit settings • thread uses temporarily to adopt a different • Inherited and explicitly-set permissions may conflict security context, usually of another user – Resolution rules • Positive permissions are additive • Negative permission (deny access) takes priority

6 Security Descriptor Example access request

uInformation associated with an object User: Mark Access Group1: Administrators • who can perform what actions on the object token Group2: Writers uSeveral fields Access request: write • Header Revision Number Action: denied Control flags – Descriptor revision number Owner SID – Control flags, attributes of the descriptor • User Mark requests write permission Group SID • Descriptor denies permission to group • E.g., memory layout of the descriptor DACL Pointer Security • Reference Monitor denies request • SID of the object's owner SACL Pointer descriptor Deny • SID of the primary group of the object Writers • Two attached optional lists: Read, Write Allow – Discretionary Access Control List (DACL) – users, groups, … Mark – System Access Control List (SACL) – system logs, .. Read, Write

Impersonation Tokens (setuid?) Encrypted File Systems (EFS, CFS)

uProcess uses security attributes of another uStore files in encrypted form • Client passes impersonation token to server • Key management: user’s key decrypts file uClient specifies impersonation level of server • Useful protection if someone steals disk • Anonymous uWindows – EFS – Token has no information about the client • User marks a file for encryption • Identification • Unique file encryption key is created – server obtain the SIDs of client and client's privileges, but • Key is encrypted, can be stored on smart card server cannot impersonate the client • Impersonation uUnix – CFS [Matt Blaze] – server identify and impersonate the client • Transparent use • Delegation • Local NFS server running on "loopback" interface – lets server impersonate client on local, remote systems • Key protected by passphrase

Q: Why use crypto file system? SELinux Security Policy Abstractions

uGeneral security questions uType enforcement • What properties are provided? • Each process has an associated domain • Against what form of attack? • Each object has an associated type uCrypto file system • Configuration files specify • What properties? – How domains are allowed to access types – Allowable interactions and transitions between domains – Secrecy, integrity, authenticity, … ? • Against what kinds of attack? uRole-based access control – Someone steals your laptop? • Each process has an associated role – Someone steals your removable disk? – Separate system and user processes – Someone has network access to shared file system? • configuration files specify Depends on how file system configured and used – Set of domains that may be entered by each role

7 Secure Operating Systems Sample Features of Trusted OS

uExtra mechanisms for extra security u Mandatory access control uFollow design and implementation procedures • MAC not under user control, precedence over DAC u Object reuse protection uReview of design and implementation • Write over old data when file space is allocated uMaintenance procedures u Complete mediation • Prevent any access that circumvents monitor u Audit Will discuss • See next slide • Mechanisms associated with secure OS u Intrusion detection • Standards for certification • Anomaly detection – Mostly used by government, some commercial interest – Learn normal activity, Report abnormal actions • Attack detection – Recognize patterns associated with known attacks

Audit Trusted path

uLog security-related events uSpoofing uProtect audit log • Fool user/process into thinking they are • Write to write-once non-volatile medium communicating with secure part of system • Intercept communication uAudit logs can become huge • Manage size by following policy uTrusted path – Storage becomes more feasible • Mechanisms to prevent spoofing – Analysis more feasible since entries more meaningful – Special key sequence for passwd command intercepted by trusted kernel (e.g, ctrl-alt-delete) • Example policies – Allow some actions only at boot time, before user – Audit only first, last access by process to a file processes loaded – Do not record routine, expected events • E.g., starting one process always loads …

Kernelized Design SELinux uTrusted Computing Base User space uSecurity-enhanced Linux system (NSA) • Hardware and software for User • Enforce separation of information based on enforcing security rules process confidentiality and integrity requirements • Mandatory access control incorporated into the major subsystems of the kernel uReference monitor – Limit tampering and bypassing of application security • Part of TCB mechanisms Reference • All system calls go through monitor – Confine damage caused by malicious applications reference monitor for TCB security checking OS kernel • Most OS not designed this way Kernel space http://www.nsa.gov/selinux/

8 Why Linux? Rainbow Series uOpen source • Already subject to public review DoD Trusted Computer Sys Evaluation Criteria (Orange Book) – This by itself does not guarantee security … Audit in Trusted Systems (Tan Book) • NSA can review source, modify and extend Configuration Management in Trusted Systems (Amber Book) • Hope to encourage additional Trusted Distribution in Trusted Systems (Dark Lavender Book) security research Security Modeling in Trusted Systems (Aqua Book) • Released under the same terms and conditions as Formal Verification Systems (Purple Book) the original sources. – includes documentation and source code Covert Channel Analysis of Trusted Systems (Light Pink Book) … many more

http://www.radium.ncsc.mil/tpep/library/rainbow/index.html

Assurance methods Orange Book Criteria (TCSEC) uTesting uLevel D • Can demonstrate existence of flaw, not absence • No security requirements uFormal verification uLevel C For environments with cooperating users • Time-consuming, painstaking process • C1 – protected mode OS, authenticated login, DAC, u“Validation” security testing and documentation (Unix) • Requirements checking • C2 – DAC to level of individual user, object initialization, auditing (Windows NT 4.0) • Design and code reviews – Sit around table, drink lots of coffee, … uLevel B, A • Module and system testing • All users and objects must be assigned a security label (classified, unclassified, etc.) • System must enforce Bell-LaPadula model

Levels B, A (continued) Orange Book Requirements (TCSEC) uLevel B uSecurity Policy • B1 – classification and Bell-LaPadula uAccountability • B2 – system designed in top-down modular way, uAssurance must be possible to verify, covert channels must be analyzed uDocumentation • B3 – ACLs with users and groups, formal TCB must be presented, adequate security auditing, secure crash recovery uNext few slides: details not important … uLevel A1 • Main point: Higher levels require more work …, • Formal proof of protection system, formal proof documentation and configuration management are that model is correct, demonstration that impl part of the criteria conforms to model, formal covert channel analysis

9 Common Criteria Protection Profiles uThree parts uRequirements for categories of systems • CC Documents • Subject to review and certified – Protection profiles: requirements for category of systems uExample: Controlled Access PP (CAPP_V1.d) • Functional requirements • Security functional requirements • Assurance requirements – Authentication, User Data Protection, Prevent Audit Loss • CC Evaluation Methodology • Security assurance requirements • National Schemes (local ways of doing evaluation) – Security testing, Admin guidance, Life-cycle support, … uEndorsed by 14 countries • Assumes non-hostile and well-managed users uReplaces TCSEC • Does not consider malicious system developers • CC adopted 1998 • Last TCSEC evaluation completed 2000 http://www.commoncriteria.org/

Evaluation Assurance Levels 1 – 4 Evaluation Assurance Levels 5 – 7

EAL 1: Functionally Tested EAL 5: Semiformally Designed and Tested • Review of functional and interface specifications • Formal model, modular design • Some independent testing • Vulnerability search, covert channel analysis EAL 2: Structurally Tested EAL 6: Semiformally Verified Design and Tested • Analysis of security functions, incl high-level design • Structured development process • Independent testing, review of developer testing uEAL 7: Formally Verified Design and Tested EAL 3: Methodically Tested and Checked • Formal presentation of functional specification • Development environment controls; config mgmt • Product or system design must be simple EAL 4: Methodically Designed, Tested, Reviewed • Independent confirmation of developer tests • Informal spec of security policy, Independent testing

Example: Windows 2000, EAL 4+ uEvaluation performed by SAIC uUsed “Controlled Access Protection Profile” uLevel EAL 4 + Flaw Remediation • “EAL 4 … represents the highest level at which products not built specifically to meet the requirements of EAL 5-7 ought to be evaluated.” (EAL 5-7 requires more stringent design and development procedures …) • Flaw Remediation uEvaluation based on specific configurations • Produced configuration guide that may be useful

10 Is Windows is “Secure”? Limitations of Secure OS uGood things uNoninterference • Design goals include security goals • Actions by high-level users (secret, top secret) • Independent review, configuration guidelines should not be observable by low-level users (unclassified, …) uBut … • Difficult to achieve and prove, not impossible • “Secure” is a complex concept – What properties protected against what attacks? • Typical installation includes more than just OS uCovert Channels – Many problems arise from applications, device drivers • Can user of system deliberately communicate – Windows driver certification program secret information to external collaborator?

Noninterference Example: Smart Card

High High Signing inputs outputs key Tamper-proof Process hardware Low Low Challenge Response inputs outputs input output

Covert Channels Outline uButler Lampson u Access Control u Secure OS • Difficulty achieving confinement (paper on web) • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks • Communicate by using CPU, locking/unlocking file, u Assurance sending/delaying msg, … u OS Policies • Multics • Orange Book, TCSEC uGustavus Simmons – Ring structure • Common Criteria • Cryptographic techniques make it impossible to • Unix • Windows 2000 detect presence of a covert channel – File system, Setuid certification • Windows u Some Limitations – File system, Tokens, EFS • Information flow • SE Linux • Covert channels – Role-based – Domain type enforcement

11