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 HW3

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? DoS 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 DoS 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 monitor allow/deny object

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) Hardware Kernel (mediates access to processor/memory) * 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 File 1File 2File 3…File n User 1{r,w}{w}{r,w} User 2{w} {r,w} User 3{r}{w} … User k{r} {r,w}{r}{w} Subjects Objects

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 monitor allow/deny object

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