CMSC 414 Computer (and Network) Security Lecture 11 Jonathan Katz.
-
Upload
wendy-hill -
Category
Documents
-
view
217 -
download
0
Transcript of CMSC 414 Computer (and Network) Security Lecture 11 Jonathan Katz.
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!
Newsgroup
Send questions to newsgroup if the answer would be of interest to other students
(If you want to reach me, send email)
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
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
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
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”)
Policy languages
Low-level policy languages– Explicit system commands that mandate certain
policy– E.g., chmod, xhost
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
“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
Assumptions/trust
Both policies and mechanisms make certain assumptions, and determinations of “trust”– Important to recognize this– Occasionally re-think these assumptions
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
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
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”
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
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
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
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)
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
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…
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
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
Requirements, continued…
The special installation process is controlled and audited
Auditors must have access to both system state and system logs
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