Notes for February 4, 1998
- Greetings and felicitations!
- Reading: Pfleeger, pp. 247-249, 277-280, 304-305
- Puzzle
- Point is that sometimes non-technical solutions are the most effective
- MULTICS ring mechanism
- MULTICS rings: used for both data and procedures; rights are REWA
- (b1, b2) access bracket - can access freely; (b3, b4) call bracket - can
call segment through gate; so if a's access bracket is (32,35) and its call
bracket is (36,39), then assuming permission mode (REWA) allows access,
a procedure in:
rings 0-31: can access a, but ring-crossing fault
occurs
rings 32-35: can access a, no ring-crossing fault
rings 36-39: can
access a, provided a valid gate is used as an entry point
rings 40-63:
cannot access a
- If the procedure is accessing a data segment d, no call bracket allowed;
given the above, assuming permission mode (REWA) allows access, a
procedure in:
rings 0-32: can access d
rings 33-35: can access d, but
cannot write to it (W or A)
rings 36-63: cannot access d
- Capabilities
- Capability-based addressing: show picture of accessing object
- Show process limiting access by not inheriting all parent's capabilities
- Revocation: use of a global descriptor table
[ ended here ]
- Lock and Key
- Associate with each object a lock; associate with each process that has
access to object a key (it's a cross between ACLs and C-Lists)
- Example: use crypto (Gifford). X object enciphered with key K.
Associate an opener R with X. Then:
OR-Access: K can be
recovered with any Di in a list of n deciphering transformations,
so R = (E1(K), E2(K), ...,
En(K)) and any process with access to any of the
Di's can
access the file
AND-Access: need all n deciphering functions to get
K: R = E1(E2(...En(K)...))
- Mandatory vs. Discretionary;
- security levels
- categories
- Bell-LaPadula Model
- Simple Security Property: no reads up
- Star Property: no writes down
- Discretionary Security Property: if mandatory controls say it's okay, check
discretionary controls.
d. Basic Security Theorem: A system is secure if its initial state is secure
and no action violates the above rules.
- ORCON (Originator Controlled; Graubert)
- Document/information can be passed on with approval of originator; real
world justification is that originator of document trusts recipients not to
release documents which they should not.
- Untrusted subject x marks object O ORCON on behalf of
organization X and indicates it is releasable to subjects acting on
behalf of organization Y.
not releasable to subjects acting on
behalf of other organizations without X's permission
any copies
made have the same restriction
c. DAC: can't do this as the restriction would not copy over (y
reads O into C, puts its own ACL on C)
- MAC: separate category withO, x, y. y wants to
read O, copy to C; MAC means C has same category as
O, x, y, so can't give z access to C.
Say
a new organization w wants to provide data in B to y but
not to be shared with x or z. Can't use O's category.
Hence you get explosion of categories.
Real world parallel: individuals are
"briefed" into a category and those represent a formal "need to know" policy
that is standard across the entity; ORCON has no central clearinghouse to
categorize data; originator makes rules.
- Solution?
- owner of object can't change ACL's relationship with object (MAC
characteristic)
- on copy, ACL is copied as well (MAC characteristic)
- access control restrictions can be tailored on a subject/object basis (DAC
characteristic)
You can also see this document
in its native format,
in Postscript,
in PDF,
or
in ASCII text.
Send email to
[email protected].
Department of Computer Science
University of California at Davis
Davis, CA 95616-8562
Page last modified on 2/14/98