CMSC 414 Computer (and Network) Security Lecture 11 Jonathan Katz.

CMSC 414Computer (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

Example security policy

See book…

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

Confidentiality policies(Chapter 5)

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

Integrity policies(Chapter 6)

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

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