CMSC 414 Computer and Network Security Lecture 17

1. CMSC 414Computer and Network SecurityLecture 17 Jonathan Katz

2. Reading on course webpage • Buffer overflows • Will get to it in about 2 weeks, but start reading now • Will be useful for HW3

3. System Security

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

5. 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

6. 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

7. 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

8. 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

9. Security Principles

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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!

18. 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

19. 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

20. 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

21. Access control

22. 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

23. 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)

24. Access control • Determining who has access to specific files, or other system resources referencemonitor subject object request allow/deny

25. 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

26. 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

27. 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)

28. 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.)

29. 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.

30. Objects Subjects Example

31. 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 referencemonitor subject object request allow/deny

32. 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

33. 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

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