Upload
lesley-jenkins
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
Outline• Overview
– Mandatory versus discretionary controls– What is a confidentiality model
• Bell-LaPadula Model– General idea– Description of rules
• Tranquility• Controversy
– †-property– System Z
1
Slide #4-2
Outline
• Policy overview• Policies versus mechanisms• High Level Policies
– E.g., DTEL
• Low Level Policies– E.g., xhost
Slide #4-3
Security Policy
• Policy partitions system states into:– Authorized (secure)
• These are states the system can enter
– Unauthorized (nonsecure)• If the system enters any of these states, it’s a security
violation
• Secure system– Starts in authorized state– Never enters unauthorized state
Slide #4-4
Authorized System States
S1 S2 S3 S4
Slide #4-5
Components of Security Addressed in Policy
• Basic Security Components– Confidentiality– Integrity– Availability
Slide #4-6
Policy Models
• Abstract description of a policy or class of policies• Types of policies
– Military (governmental) security policy• Policy primarily protecting confidentiality
– Commercial security policy• Policy primarily protecting integrity
– Confidentiality policy• Policy protecting only confidentiality
– Integrity policy• Policy protecting only integrity
– Service Level Agreements• Availability agreements
Slide #4-7
Question
• Policy disallows cheating– Includes copying homework, with or without
permission
• CS class has students do homework on computer• Anne forgets to read-protect her homework file• Bill copies it• Who cheated?
– Anne, Bill, or both?
Slide #4-8
Answer Part 1
• Bill cheated– Policy forbids copying homework assignment– Bill did it– System entered unauthorized state (Bill having a copy of
Anne’s assignment)
• If not explicit in computer security policy, certainly implicit– Not credible that a unit of the university allows
something that the university as a whole forbids, unless the unit explicitly says so
Slide #4-9
Answer Part #2
• Anne didn’t protect her homework– Not required by security policy
• She didn’t breach security• If policy said students had to read-protect
homework files, then Anne did breach security– She didn’t do this
Slide #4-10
Mechanisms
• Entity or procedure that enforces some part of the security policy– Access controls (like bits to prevent someone
from reading a homework file)– Disallowing people from bringing CDs and
floppy disks into a computer facility to control what is placed on systems
Slide #4-11
Policy Languages
• Express security policies in a precise way• A continuum of policy languages
– English Policies• May be legally precise. Used as basis for legal action.• May be written imprecisely just to give real users a sense of
the policy• More in later lecture
– High-level languages• Policy constraints expressed abstractly
– Low-level languages• Policy constraints expressed in terms of program options,
input, or specific characteristics of entities on system
Slide #4-12
High-Level Policy Languages
• Constraints expressed independent of enforcement mechanism
• Constraints restrict entities, actions• Constraints expressed unambiguously
– Requires a precise language, usually a mathematical, logical, or programming-like language
• Examples– Java constraint language – described in CS:A&S– DTEL type enforcement language– SAML http://xml.coverpages.org/saml.html– IETF Policy models ftp://ftp.rfc-editor.org/in-notes/rfc3585.txt
Slide #4-13
DTEL – Domain Type Enforcement Language
• Basis: access can be constrained by types• Combines elements of low-level, high-level policy
languages– Implementation-level constructs express constraints in terms of
language types– Constructs do not express arguments or inputs to specific system
commands• Used in Sidewinder firewalls• Details of DTEL in
http://citeseer.ist.psu.edu/cache/papers/cs/16179/http:zSzzSzwww.cs.ubc.cazSzspiderzSzabrodskyzSzdosezSzbadger.95.pdf/badger96domain.pdf
• Type enforcement policies resurfacing in SE Linux
Boebert, Kain 85
Slide #4-14
Example
• Goal: users cannot write to system binaries• Subjects in administrative domain can
– User must authenticate to enter that domain
• Subjects belong to domains:– d_user ordinary users– d_admin administrative users– d_login for login– d_daemon system daemons
Slide #4-15
Types
• Object types:– t_sysbin executable system files– t_readablereadable files– t_writable writable files– t_dte data used by enforcement mechanisms– t_generic data generated from user processes
• For example, treat these as partitions– In practice, files can be readable and writable; ignore
this for the example
Slide #4-16
Domain Representation
• Sequence– First component is list of programs that start in
the domain– Other components describe rights subject in
domain has over objects of a type(crwd->t_writable)
means subject can create, read, write, and list (search) any object of type t_writable
Slide #4-17
d_daemon Domain
domain d_daemon = (/sbin/init),
(crwd->t_writable),
(rd->t_generic, t_readable, t_dte),
(rxd->t_sysbin),
(auto->d_login);
• Compromising subject in d_daemon domain does not enable attacker to alter system files– Subjects here have no write access
• When /sbin/init invokes login program, login program transitions into d_login domain
Slide #4-18
d_admin Domain
domain d_admin =
(/usr/bin/sh, /usr/bin/csh, /usr/bin/ksh),
(crwxd->t_generic),
(crwxd->t_readable, t_writable, t_dte,
t_sysbin),
(sigtstp->d_daemon);
• sigtstp allows subjects to suspend processes in d_daemon domain
• Admin users use a standard command interpreter
Slide #4-19
d_user Domain
domain d_user =
(/usr/bin/sh, /usr/bin/csh, /usr/bin/ksh),
(crwxd->t_generic),
(rxd->t_sysbin),
(crwd->t_writable),
(rd->t_readable, t_dte);
• No auto component as no user commands transition out of it
• Users cannot write to system binaries
Slide #4-20
d_login Domain
domain d_login =
(/usr/bin/login),
(crwd->t_writable),
(rd->t_readable, t_generic, t_dte),
setauth,
(exec->d_user, d_admin);
• Cannot execute anything except the transition– Only /usr/bin/login in this domain
• setauth enables subject to change UID• exec access to d_user, d_admin domains
Slide #4-21
Set Up
initial_domain = d_daemon;
– System starts in d_daemon domainassign -r t_generic /;
assign -r t_writable /usr/var, /dev, /tmp;
assign -r t_readable /etc;
assign -r -s dte_t /dte;
assign -r -s t_sysbin /sbin, /bin,
/usr/bin, /usr/sbin;
– These assign initial types to objects– –r recursively assigns type– –s binds type to name of object (delete it, recreate it, still
of given type)
Slide #4-22
Add Log Type
• Goal: users can’t modify system logs; only subjects in d_admin, new d_log domains can
type t_readable, t_writable, t_sysbin,
t_dte, t_generic, t_log;
• New type t_logdomain d_log =
(/usr/sbin/syslogd),
(crwd->t_log),
(rwd->t_writable),
(rd->t_generic, t_readable);
• New domain d_log
Slide #4-23
Fix Domain and Set-Up
domain d_daemon =
(/sbin/init),
(crwd->t_writable),
(rxd->t_readable),
(rd->t_generic, t_dte, t_sysbin),
(auto->d_login, d_log);
– Subject in d_daemon can invoke logging process– Can log, but not execute anything
assign -r t_log /usr/var/log;
assign t_writable /usr/var/log/wtmp, /usr/var/log/utmp;
– Set type of logs
Slide #4-24
Low-Level Policy Languages
• Set of inputs or arguments to commands– Check or set constraints on system
• Low level of abstraction– Need details of system, commands
• Can think of as specific configuration languages. Generally very closely tied to an application.
• Examples:– Xhost– Unix file system access commands– Tripwire integrity databases– IOS router CLI – Could argue IOS ACL’s are higher level
Slide #4-25
Example: X Window System
• UNIX X11 Windowing System• Access to X11 display controlled by list
– List says what hosts allowed, disallowed accessxhost +groucho -chico
• Connections from host groucho allowed• Connections from host chico not allowed
Slide #4-26
Example: tripwire
• File scanner that reports changes to file system and file attributes– tw.config describes what may change/usr/mab/tripwire +gimnpsu012345678-a
• Check everything but time of last access (“-a”)
– Database holds previous values of attributes
Kim, Spafford 94
Slide #4-27
Example Database Record
/usr/mab/tripwire/README 0 ..../. 100600 45763 1 917 10 33242 .gtPvf .gtPvY .gtPvY 0 .ZD4cc0Wr8i21ZKaI..LUOr3 .0fwo5:hf4e4.8TAqd0V4ubv ?...... ...9b3 1M4GX01xbGIX0oVuGo1h15z3 ?:Y9jfa04rdzM1q:eqt1APgHk ?.Eb9yo.2zkEh1XKovX1:d0wF0kfAvC ?1M4GX01xbGIX2947jdyrior38h15z3 0
• file name, version, bitmask for attributes, mode, inode number, number of links, UID, GID, size, times of creation, last modification, last access, cryptographic checksums
Slide #4-28
Comments
• System administrators not expected to edit database to set attributes properly
• Checking for changes with tripwire is easy– Just run once to create the database, run again to
check
• Checking for conformance to policy is harder– Need to either edit database file, or (better) set system
up to conform to policy, then run tripwire to construct database
Slide #4-29
Key Points
• Policies describe what is allowed• Mechanisms control how policies are
enforced• Spectrum of styles of policy languages• Next time: confidentiality models
Confidentiality
• What is confidentiality?
Confidentiality Policy
• Goal: prevent the unauthorized disclosure of information– Deals with information flow– Integrity incidental
• Example:– Students may not have access to grade files
31
MAC vs DAC• Discretionary Access Control (DAC)
– Access governed by normal users– Owner of a resource can designate permissions– Standard model for Unix, Linux, Windows, etc.– Access control is at the discretion of the user– Implements user’s policy
32
MAC
• Mandatory Access Control (MAC)– Access rules are set system-wide– Normal users cannot violate system-wide rules, even for
resources they “own” (e.g. create)– Implements organizational policy– Usually combined with DAC to add discretion
• Applications– Multi-level military security– Bell-LaPadula Model
Bell-LaPadula Model, Step 1• Security levels arranged in linear ordering
– Top Secret: highest– Secret– Confidential– Unclassified: lowest
• Subjects have security clearance L(s)• Objects have security classification L(o)
34Bell, LaPadula 73
Example
35
objectsubjectsecurity level
Syllabus
Assignments
Assignment Solutions
Grade Files
EveryoneUnclassified
StudentsConfidential
TASecret
NikitaTop Secret
• Nikita can read all files• Students cannot read grade files or assignment solutions• Students not in 461 can only read syllabus
Reading Information• Information flows up, not down
– “Reads up” disallowed, “reads down” allowed• Simple Security Condition (Step 1)
– Subject s can read object o iff, L(o) ≤ L(s) and s has permission to read o
• Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)
– Sometimes called “no reads up” rule
36
Writing Information• Information flows up, not down
– “Writes up” allowed, “writes down” disallowed• *-Property (Step 1)
– Subject s can write object o iff L(s) ≤ L(o) and s has permission to write o
• Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)
– Sometimes called “no writes down” rule
37
Basic Security Theorem, Step 1• If a system is initially in a secure state, and
every transition of the system satisfies the simple security condition (step 1), and the *-property (step 1), then every state of the system is secure– Proof: induction on the number of transitions
• Meaning of “secure” in axiomatic
38
Need to Know• Consider the notion of “need-to-know”• Example:
– Two sections for a class, with two TAs– TA1 doesn’t need to know grades for section 2, and vice versa– Cannot introduce linear ordering between TAs to enforce this
• Military applications:– Different operations– Someone cleared for Top Secret on operation X may not need to
know even unclassified documents on operation Y
39
Bell-LaPadula, Step 2
• Expand notion of security level to include categories (also called compartments)
• Security level is (clearance, category set)• Examples
– ( Top Secret, { NUC, EUR, ASI } )– ( Confidential, { EUR, ASI } )– ( Secret, { NUC, ASI } )
Levels and Lattices• (A, C) dom (A, C) iff A ≤ A and C C• Examples
– (Top Secret, {NUC, ASI}) dom (Secret, {NUC})– (Secret, {NUC, EUR}) dom (Confidential,{NUC, EUR})– (Top Secret, {NUC}) dom (Confidential, {EUR})– (Secret, {NUC}) dom (Confidential,{NUC, EUR})
• Let C be set of classifications, K set of categories. Set of security levels L = C K, dom form lattice– Partially ordered set– Any pair of elements
• Has a greatest lower bound• Has a least upper bound
41
Example Lattice
42
ASI,NUC ASI,EUR
ASIEUR
NUC
NUC,EUR
ASI,NUC,EUR
Subset Lattice
43
TS:NUC,EUR
TS:NUC,ASITS:NUC
S:NUC
C:NUC,EUR
C:EUR
U:
TS: ASI,NUC,EUR
Levels and Ordering• Security levels partially ordered
– Any pair of security levels may (or may not) be related by dom
• “dominates” serves the role of “greater than” in step 1– “greater than” is a total ordering, though
44
Reading Information• Information flows up, not down
– “Reads up” disallowed, “reads down” allowed• Simple Security Condition (Step 2)
– Subject s can read object o iff L(s) dom L(o) and s has permission to read o
• Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)
– Sometimes called “no reads up” rule
45
Writing Information• Information flows up, not down
– “Writes up” allowed, “writes down” disallowed• *-Property (Step 2)
– Subject s can write object o iff L(o) dom L(s) and s has permission to write o
• Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)
– Sometimes called “no writes down” rule
46
Basic Security Theorem, Step 2• If a system is initially in a secure state, and
every transition of the system satisfies the simple security condition (step 2), and the *-property (step 2), then every state of the system is secure– Proof: induct on the number of transitions– In actual Basic Security Theorem, discretionary
access control treated as third property, and simple security property and *-property phrased to eliminate discretionary part of the definitions — but simpler to express the way done here.
47
Problem• One-way flow of information may be too
restrictive• E.g. Colonel with Top Secret clearance cannot
write to anywhere a Major with Secret clearance can read– Is this a problem?
48
Solution• Define maximum, current levels for subjects
– maxlevel(s) dom curlevel(s)• Example
– Treat Major as an object (Colonel is writing to him/her)– Colonel has maxlevel (Secret, { NUC, EUR })– Colonel sets curlevel to (Secret, { EUR })– Now L(Major) dom curlevel(Colonel)
• Colonel can write to Major without violating “no writes down”– Does L(s) mean curlevel(s) or maxlevel(s)?
• Formally, we need a more precise notation
49
Adjustments to “write up”• Write permission usually allows read/write
access to object– So both simple security condition and *-property
apply– S dom O and O dom S means S=O
• BLP discuss append as a “pure” write so “write up” still applies
50
Principle of Tranquility
• Raising object’s security level– Information once available to some subjects is no longer
available– Usually assume information has already been accessed, so
this does nothing• Lowering object’s security level
– The declassification problem– Essentially, a “write down” violating *-property– Solution: define set of trusted subjects that sanitize or
remove sensitive information before security level lowered
51
Types of Tranquility
• Strong Tranquility– The clearances of subjects, and the classifications
of objects, do not change during the lifetime of the system
• Weak Tranquility– The clearances of subjects, and the classifications
of objects change in accordance with a specified policy.
52
Example• DG/UX System
– Only a trusted user (security administrator) can lower object’s security level
– In general, process MAC labels cannot change• If a user wants a new MAC label, needs to initiate new
process• Cumbersome, so user can be designated as able to
change process MAC label within a specified range
• Other systems allow multiple labeled windows to address users operating a multiple levels
53
Controversy• McLean:
– “value of the BST is much overrated since there is a great deal more to security than it captures. Further, what is captured by the BST is so trivial that it is hard to imagine a realistic security model for which it does not hold.”
54McLean 85
Definition of Security• BLP define security in terms of *-property• State (b, m, f, h) satisfies the *-property iff for each s S
the following hold:1. b(s: a) ≠ [o b(s: a) [ fc(o) dom fo(s) ] ]
2. b(s: w) ≠ [o b(s: w) [ fo(o) = fc(s) ] ]
3. b(s: r) ≠ [o b(s: r) [ fc(s) dom fo(o) ] ]
55
Redefinition: †-property
• State (b, m, f, h) satisfies the †-property iff for each s S the following hold:1. b(s: a) ≠ [o b(s: a) [ fc(s) dom fo(o) ] ]
2. b(s: w) ≠ [o b(s: w) [ fo(o) = fc(s) ] ]
3. b(s: r) ≠ [o b(s: r) [ fc(s) dom fo(o) ] ]
• Idea: for writing, subject dominates object; for reading, subject also dominates object
• Differs from *-property in that the mandatory condition for writing is reversed– For *-property, it’s object dominates subject
AnaloguesThe following two theorems can be proved (R, D, W, z0) satisfies the †-property relative to S S for any
secure state z0 iff for every action (r, d, (b, m, f, h), (b, m, f, h)), W satisfies the following for every s S´– Every (s, o, p) b – b satisfies the †-property relative to S– Every (s, o, p) b that does not satisfy the †-property relative to S is
not in b (R, D, W, z0) is a “secure” system if z0 is a secure state and W
satisfies the conditions for the simple security condition, the †-property, and the ds-property.
57
Problem• This system is clearly non-secure!
– Information flows from higher to lower because of the †-property
58
Key Points• Confidentiality models restrict flow of
information• Bell-LaPadula models multilevel security
– Cornerstone of much work in computer security
• Definition of security as important as model for enforcing it
61