CMSC 414 Computer and Network Security Lecture 17

CMSC 414 Computer and Network Security Lecture 17 Jonathan Katz

Reading on course webpage ¨ Buffer overflows ¨ Will get to it in about 2 weeks, but start reading now ¨ Will be useful for HW 3

System Security

“System security” ¨ Several meanings of “system security” here: – Security of the entirety of what is being protected – Operating-system security – Host security

System security -- components ¨ Policy (specification) – What security properties to focus on – What is and is not allowed ¨ Mechanism (implementation) – The mechanism enforces the policy – Includes procedural controls, not just technical ones • E. g. , who may enter the room where backup tapes are stored • How new accounts are established – Prevention/detection/response/recovery ¨ Assurance (correctness) – Verifying that the mechanism implements the policy

Security policy ¨ Formal statement of rules and practices that specify what a system or organization will protect, and how it will do so ¨ Useful to also specify threat model

Mechanisms for enforcing policy ¨ The precision of a mechanism measures how closely the mechanism matches the policy – E. g. , an overly restrictive mechanism may prevent things that are allowed by the policy ¨ Hard (in general) to develop a “maximally- precise” mechanism for an arbitrary given policy ¨ Impossible (in general) to determine whether a given mechanism implements a given policy ¨ Made worse by the fact that policy is often specified informally to begin with

Assurance/evaluation ¨ The degree of confidence in the ability to carry out the policy ¨ Encompasses both design and implementation ¨ Evaluation – Examining computer/system with respect to certain criteria – Testing, formal analysis

Security Principles

General principles ¨ Seminal article by Saltzer and Schroeder (1975) – Linked from the course homepage ¨ Eight principles underlying design and implementation of security mechanisms ¨ These are guidelines, not hard and fast rules ¨ Not exhaustive

Principle 1 ¨ “Principle of least privilege” – A subject should be given only the privileges it needs to accomplish its task • E. g. , only allow access to information it needs • E. g. , only allow necessary communication – The function of a subject (not its identity) should determine this • I. e. , if a subject needs some privileges to complete a specific task, it should relinquish those privileges upon completion • If reduced privileges are sufficient for a given task, the subject should request only those privileges

In practice… ¨ There is a limit to how much granularity a system can handle ¨ Systems are often not designed with the necessary granularity – E. g. , “append” may not be distinct from “write” – E. g. , in UNIX, nothing between user and root • Anyone who can make backup files can also delete those files

Principle 2 ¨ “Principle of Fail-Safe Defaults” – Unless a subject is given explicit access to an object, it should be denied access • I. e. , the default is no access – More generally, in case of ambiguity the system should default to the more restrictive case

Principle 3 ¨ “Economy of Mechanism” – Security mechanisms should be as simple as possible… – This applies to both the policy and the mechanism! – Less chance of error – Can simplify assurance process ¨ Offering too much functionality can be dangerous – E. g. , finger protocol: cap how much information can be returned, or allow an arbitrary amount? • Do. S attack by returning an infinite stream of characters – E. g. , macros in Excel, Word – E. g. , postscript can execute arbitrary code

Principle 4 ¨ “Principle of Complete Mediation” – All accesses to objects should be checked to ensure they are allowed – OS should mediate any request to read an object --even on the second such request by the same subject! • Don’t cache authorization results • Don’t rely on authentication/authorization performed by another module – Time-of-check-to-time-of-use flaws… ¨ Good examples: re-authentication (on websites, or systems) when performing sensitive tasks

Insecure example… ¨ In UNIX, when a process tries to read a file, the system checks access rights – If allowed, it gives the process a file descriptor – File descriptor is presented to OS for access ¨ If permissions are subsequently revoked, the process still has a valid file descriptor! – Insufficient mediation

Principle 5 ¨ “Open Design” – No “security through obscurity” – Security of a system should not depend on the secrecy of its implementation • Of course, secret keys do not violate this principle!

Principle 6 ¨ “Separation of Privilege” – (As much as is feasible…) a system should not grant permission based on a single condition – E. g. , require more than one sys admin to issue a critical command, or more than one teller to issue an ATM card

Principle 7 ¨ “Principle of Least Common Mechanism” – Minimize mechanisms depended upon by all users • Minimize effect of a security flaw! – Shared mechanisms are a potential information path, and so may be used to compromise security – Shared mechanisms also expose the system to potential Do. S attacks

Principle 8 ¨ “Psychological Acceptability” – Security mechanisms should not make access to the resource more difficult – If mechanisms are too cumbersome, they will be circumvented! – Even if they are used, they may be used incorrectly

Access control

Multi-user vs. single-user systems ¨ Two kinds of multi-user systems – Explicit awareness of other users (think unix file systems) – Users unaware of each other (think cloud computing) – In either case, users’ files and applications must be protected from illegal access by other users ¨ Single-user system – Desktop PC – Still don’t want one application to illegally access data / memory belonging to another application

Multi-user vs. single-user systems ¨ ‘Classical’ computing was on a multi-user system (time-sharing systems) ¨ Gradual shift to single-user systems (home PCs), though multi-user systems were still used in business, govt. ¨ More recently, momentum is going back to multi- user systems (cloud computing)

Access control ¨ Determining who has access to specific files, or other system resources subject request reference allow/deny object monitor

Authentication vs. authorization ¨ Authentication – Determining the identity of a user – May also involve verification of IP address, machine, time, etc… – Determine whether a user is allowed to access the system at all – Used for audit, not just authorization – We have already covered authentication protocols ¨ Authorization (access control) – Assuming identity of user is known, determine whether some specific action is allowed

Design considerations ¨ Where to implement access control? Applications Services/middleware (DBMS*, object reference broker) OS (file/memory management, I/O) Kernel (mediates access to processor/memory) Hardware *Database management system

Design considerations ¨ Access control generally must be implemented in several layers ¨ For example: – In the OS, access control done at the granularity of files. But consider a (single file containing a) grades spreadsheet: the application will have to ensure that each student can only read their own grade (while the instructor can read and write everything)

Some terminology ¨ Protected entities: “objects” O ¨ Active objects: “subjects” S (i. e. , users/processes) – Note that subjects can also be objects – Typically, each subject associated with some principal/owner ¨ Subjects/objects can be: – Users – Files – Processes – System resources (servers, printers, etc. )

Access control matrix ¨ Matrix indexed by all subjects and objects – Characterizes rights of each subject with respect to each object ¨ Formally: set of objects O and subjects S, set of possible rights ¨ Matrix A with subjects labeling the rows and objects labeling the columns – The entry (s, o) contains the rights for s on o – Examples: read/write/execute/etc.

Example Objects Subjects File 1 File 2 User 1 {r, w} {w} User 2 {w} File 3 … File n {r, w} User 3 {r} {w} … User k {r} {r, w}

Access control matrix ¨ The access control matrix provides a useful way to think about the rights in the system ¨ It can also be a way to implement access control subject request reference allow/deny object monitor

More complex access control ¨ In general, “rights” may be functions – “Actual” rights depend on the system state – Equivalently, may depend on system history ¨ Rights can form hierarchies – E. g. , right X implies right Y

Granularity ¨ Granularity is an issue at the level of subjects, objects, and rights ¨ In theory, arbitrary level of granularity, e. g. , – Subjects: functions within processes – Objects: characters within files – Rights: write, append, increment-only, … ¨ In practice, a decision must be made as to the level of granularity that will be supported

Granularity ¨ Trade-off is obvious: – Fine-grained access control gives “better security” • Least privilege – Coarse-grained access control more efficient