CMSC 414 Computer and Network Security Lecture 9 Jonathan Katz

Announcements  Midterm on March 6 –Will cover material through March 4 –Anyone using DSS please speak to me after class  Next homework out later this week

System Security

System security  General principles  Access control, access control policies  Trusted computing  Memory protection

System security -- components  Policy (specification) –Important to specify –Consider various tradeoffs  Mechanism (implementation) –Prevention –Detection –Response –Recovery  Assurance –Verifying that the mechanism implements the policy

Security policy  Security policy classifies system states as “secure” or “insecure” –“System state” may potentially include everything… –In practice, a full specification of this sort is impossible  A secure system starts in a “secure” state and cannot enter an “insecure” state –“Breach of security” occurs when a system enters an “insecure” state  Policy may also indicate other desirables –Availability, confidentiality

Security mechanism  A security mechanism enforces (part of) the security policy  Includes procedural/operational controls, not just technical controls –E.g., who may enter the room in which backup tapes are stored –How new accounts are established

Mechanisms for enforcing policy  The precision of a mechanism is a measure of how overly-restrictive the mechanism is with respect to the policy –I.e., due to preventing things that are allowed  Unfortunately, impossible (in general) to develop a “maximally-precise” mechanism for an arbitrary given policy

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

Key point I  Simplicity –Make designs/mechanisms/requirements easy to understand and use –This applies to both the policy and the mechanism! –Less chance of error

Key point II  Restriction –Minimize the “power” of an entity E.g., only allow access to information it needs E.g., only allow necessary communication; restrict type of communication allowed –Less chance of harm!

Principle 1  “Principle of least privilege” –A subject should be given only the privileges it needs to accomplish its task –The function of a subject (not its identity) should determine this I.e., if a subject needs certain privileges only to complete a specific task, it should relinquish those privileges upon completion of the task 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

Principle 3  “Economy of Mechanism” –Security mechanisms should be as simple as possible… –…but no simpler! –Can simplify formal proofs of security (or even informal audits)

Rationale  If design/implementation are simple, less chance for error  Software testing is also simpler  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

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

Insecure example  Race condition –E.g., consider what happens if reading a file is done as: if (allowed(user, “r”, memory_location(filename)) then allow(user, “r”, memory_location(filename)) What if memory_location(filename) changes in the interim? –A related flaw was present in early versions of unix

Secure examples  Re-authentication on amazon.com  Re-authentication to change password

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 –Shared mechanisms are a potential information path, and should not compromise security –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

Principles in Practice

Morris worm (1988)  Exploited buffer overflow flaw in fingerd  Also exploited flaw in sendmail –Sendmail had root privilege when run in debug mode  Violations? –Principle of least privilege –Separation of privilege –Economy of mechanism (sendmail program too complex!)

Melissa virus/worm (1999)  Word macro… –When file opened, would create and send infected document to names in user’s Outlook Express mailbox –Recipient would be asked whether to disable macros(!) If macros enabled, virus would launch  Violations? –Psychological acceptability (should users have to decide whether to enable macros?) –Principle of least privilege –Open design? –Others?

OS Security

Overview  Traditional OS security motivated by multi-user systems where users are aware of each other –E.g., unix –This is what we focus on in this segment  There is a movement away from such systems –Computing done on desktop PC, and/or on a remote (shared) server but without “awareness” of other users –How do you share files with your friends? file web link to file P2P model

Differences  In multi-user context, threats are unauthorized reading/modification of files, or unauthorized use of system resources by legitimate users  In desktop PC context, the threat is having a virus take control of your machine (applies to administrators of remote servers as well)  In remote server context, the threat is unauthorized use of systems resources by legitimate users –This setting can also be viewed as a simplified multi- user setting (“regular” users vs. sys admins)

Here…  Our focus here is on multi-user systems  These are still used in business environments (shared files, shared databases, etc.)

Authentication vs. authorization  Authentication –Determining the identity of a user –May also require verification of IP address,machine, time, etc… –Determine whether a user is allowed to access the system at all –We will return to this later; for now we assume it  Authorization –Assuming the identity of the user is known (and the user is allowed to access the system), determine whether some specific action is allowed

Access control

Some terminology  Protected entities: “objects” O  Active objects: “subjects” S (i.e., users/processes) –Note that subjects can also be objects  Subjects/objects can be: –Files –Processes –Servers –Functions/variables (within a program) –Database entries –System resources (printers, etc.)

General principles  Fine-grained access control is better –E.g., control access to files not just directories  Least privilege –Grant minimum abilities necessary to complete task  Closed vs. open policies –Closed = disallowed unless explicitly allowed –Open = allowed unless explicitly disallowed  Conflict resolution –Prevent conflicts, or know how to deal with them

Access control policies  Discretionary access control (DAC)  Mandatory access control (MAC)  Role-based access control (RBAC)  Not necessarily mutually exclusive –A system may use different mechanisms for different resources –Or, apply two policies; allow access only if both allow

DAC  Controls based on the identity of the user and access rules  Rights can be delegated at users’ discretion  Most common

MAC  Controls based on comparing security labels with security clearances  Delegation not allowed  Primarily used in military applications

RBAC  Controls based on a user’s (or program’s) role, not their identity  User’s rights can change depending on their current role  More recent proposal

Discretionary access control

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

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  How fine-grained the access control is depends on how fine-grained the rights are –E.g., “write” vs. “append-only”

Coarse-grained access control  Access control can also be more coarse-grained than a full-blown access matrix would imply  E.g., in unix: –For a file, specify access rights for the owner, the group to which the owner belongs, and everyone else –Possible rights are: read, write, execute