CMSC 414 Computer (and Network) Security Lecture 11

1. CMSC 414Computer (and Network) SecurityLecture 11 Jonathan Katz

2. Midterm? • Will be held Oct 21, in class • Will cover everything up to and including the preceding lecture (Oct 16) • Includes all reading posted on the class syllabus!

3. Newsgroup • Send questions to newsgroup if the answer would be of interest to other students • (If you want to reach me, send email)

4. Security policies • “Military security policy” is primarily concerned with confidentiality • Does not exclude other concerns… • “Commercial security policy” is primarily concerned with integrity (think: banking industry) • E.g., consistent transactions • The question of “trust” is much harder than the question of confidentiality

5. A few words about trust • Everything rests on certain assumptions… • E.g., sys admin applies patch; has this improved security? • Assumptions • Patch was not tampered with • Patch itself works correctly • Patch will work correctly in new environment • Patch installed/configured correctly • Sys admin trustworthy

6. Access control • Discretionary access control • User can allow/deny access to objects • Also called identity-based access control • Mandatory access control • System-wide mechanism allows/denies access • E.g., root may have read access to all files • Also called rule-based access control

7. Policy languages • Language for representing security policy • High-level policy languages • Formal specification of policy • Example: deny(x op x) when b • E.g., deny(file.read) when (file.getname() = “/etc/passwd”)

8. Policy languages • Low-level policy languages • Explicit system commands that mandate certain policy • E.g., chmod, xhost

9. Example security policy • See book…

10. Covert channels • Information may be leaked in unexpected ways • E.g., timing difference between login with incorrect username or incorrect password • Error messages (e.g., learn filenames) • Side effects (e.g., values of other variables) • Printers, monitors, external hardware • These should be taken into account when designing security mechanism/policy

11. “Precision” of a mechanism • 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, it is impossible (in general) to develop a “maximally-precise” mechanism for an arbitrary policy

12. Assumptions/trust • Both policies and mechanisms make certain assumptions, and determinations of “trust” • Important to recognize this • Occasionally re-think these assumptions

13. Confidentiality policies (Chapter 5)

14. Bell-LaPadula model • Security classes with linear ordering • Subjects have security clearance • Objects have security classification • Prevent read access to objects with security classification higher than the subject’s security clearance

15. Access control • Can combine Bell-LaPadula model with discretionary access control as well • Simple security condition: S can read O if and only if lo ls and S has discretionary read access to O

16. Potential problems? • What if I have clearance to read a file, but copy it into an unclassified location? • Potential security breach • *-property • S can write O if and only if ls lo and S has discretionary write access to O • “Read down; write up”

17. Basic security theorem • If a system begins in a secure state, and always preserves the simple security condition and the *-property, then the system will always remain in a secure state

18. Categories • We can extend the model by adding categories to each security classification • A category describes a kind of information • Objects may be in multiple categories; subjects may have access to multiple categories • May be represented as a lattice • “Need to know” principle

19. Security levels • Each security classification and category form a security level • Informally, a subject can read an object only if (1) the subject’s security clearance are at least the security classification of the object; and (2) the subject’s categories include the categories of the object

20. More formally… • Say (L, C) dominates (L’, C’) if: • L’  L and C’  C • This modifies the simple security condition as follows: • S can read O if and only if the security level of S dominates the security level of O (and S has discretionary read access to O)

21. Similarly… • The *-property is modified as follows: • S can write to O if and only if the security level of O dominates the security level of S (and S has discretionary write access to O) • Basic security theorem modified accordingly • Note that if A does not dominate B, this does not imply that B dominates A

22. Communicating down… • How to communicate from a higher security level to a lower one? • Maximum security level and current security level • Maximum security level must always dominate the current security level • Reduce security level to write down…

23. Controversy about BL model • Does the basic security theorem say anything meaningful? • Or is it just a tautology? • In any case, the Bell-LaPadula model is useful

24. Integrity policies (Chapter 6)

25. Some requirements/assumptions • Users will not write their own programs • Will use existing programs and databases • Programs will be written/tested on a nonproduction system • Special process must be followed to install new program on production system

26. Requirements, continued… • The special installation process is controlled and audited • Auditors must have access to both system state and system logs

27. Some corollaries… • “Separation of duty” • Basically, have multiple people check any critical functions (e.g., software installation) • “Separation of function” • Develop new programs on a separate system • Auditing • Recovery/accountability

28. Commercial vs. military systems • The Bell-LaPadula model does not work as well for commercial systems • Users given access to data as needed • Would require large number of categories and classifications • Decentralized handling of security clearances • Desire to release some information