MAC_ DAC and safety

Document Sample
MAC_ DAC and safety Powered By Docstoc
					DAC models and Safety
    Mandatory Access Control
• Users, processes are given a clearance
• Objects, resources are given a label
• Central administration
• Allows for information flow policies
  (Bell-LaPadula, Biba)
• RBAC
    Discretionary Access Control
•   Access is granted to users, or user groups
•   When users create objects, they own them
•   Users can grant rights, they have, to others
•   Users that have control can remove rights
   Discretionary Access Control
• NCSC: “the basis for DAC is that an
  individual user (or program on its behalf) is
  allowed to specify explicitly the types of
  access other users (or programs on their
  behalf) may have to information under the
  user’s control”
               DAC models
•   Take-grant model
•   Lampson (1974)
•   Graham-Denning (1972)
•   Harrison-Rizzo-Ullman (1976)
•   Griffiths-Wade (1976)
•   Originator control (1989)
            Safety problem
• Does there exist an algorithm for
  determining whether a given protection
  system with initial state s0 is safe with
  respect to a generic right r?
• Answer, no! (related to halting problem)
• For which type of protection systems does
  such a procedure exist?
                Lampson
• Foundation of a protection system are the
  contexts or the protection environments:
  Lampson calls them domains
• E.g. a multi-user system with protected
  resources and processes: one domain per
  user
       Simple general setting
• Message system for otherwise isolated
  processes.
• Allows for collaboration between processes
• Senders can not force an entry, but receiver
  may use different entry points
• Drawbacks:
  – Processes can not be stopped
  – Coordinate calls and responses
    Lampson‟s Object System
• Set of objects X
• Set of domains D (think users)
• Access Matrix A (D x D and D x X)
  – Entries are sets of strings called access
    attributes (read, write, call)
  – owns, controls for administration of rights
                  Sample




• Control on a domain, means you can
  remove rights
• * is called the copy flag, i.e. delegation
• Owner can give any rights
                 Sample




• control: D1 can remove call right of D2
• * flag: D1 can give D2 the right to read
• owner: D3 can give D2 any right on f2
              Additions…
• An owner can give rights to a domain over
  which it has no control, so it can not remove
  these rights later (solution: protected flag)
• A domain controller can not prevent other
  rights to be added (solution: augment flag)
            Implementation
• File handler creates fresh object name, and
  assigns ownership to creator
• File handler keeps a matrix of files and
  domains (a part of A), to deal with file
  access requests
• If A is sparse, store the columns (lists of
  capabilities) per domain
• Or store rows (authorized domains) per file
            Graham-Denning
•   Set of subjects (processes, users)
•   Set of objects
•   Matrix of rights (read, write, own, exec)
•   Owns means can add and revoke any rights
        Example LAN rights



• Telegraph is an ftp client
• nob and toadflax exchange mail
       Example: Statistical DB
• A statistical database:
  – Answers queries about groups, prevents users
    to know individual entries
  – Query-set-overlap control: when the size of the
    intersection of the query set and each previous
    query set is smaller than some parameter
  – After each query, access rights are changed
                     HRU model
• Protection system is a triple of subjects, objects
  and an access matrix
• Change of protection-system is modelled by 6
  primitive operations
   –   enter r into (s,o)
   –   delete r from (s,o)
   –   create subject s
   –   create object o
   –   destroy subject s
   –   destroy object o
     HRU for Graham-Denning
• command CREATE(process, file):
  – create object file
  – enter own into (process, file)
• command CONFER(a, b, right, file):
  – if own in (a, file)
  – then enter right into (b, file)
• command REMOVE(a, b, right, file):
  – if own in (a, file)
  – then delete right from (b, file)
               HRU for Unix
• each file has one owner
• owner may specify his own rights, and the
  rights of all
• use a (file, file) entry, specifying the rights
  for all
• user u can read file f,
   – if own in (u,f) and ownerread in (f,f)
   – or if allcanread is in (f,f)
              HRU and Safety
• Can some subject attain a certain right, without
  concurrence of the owner
• But delegation or decentralization of authority is
  common
• Can we tell, whether a certain operation leads to
  leakage of a right, in a later operation
• Trivially unsafe, so Harrison et al. remove all the
  trusted subjects
                HRU and Safety
• Given initial config Q, does a certain command c
  leak a certain right r: can c, applied on Q, enter r
  into the access matrix
• Given Q is there any command that can enter r
  into the matrix
• Mono-operational HRU model
   – only commands are primitive operations
   – not very useful, unix createfile cannot be handled
   – Safety can be decided
      • Just create one subject, and then try all possible enter
        commands
• In a general HRU model this is undecidable
           Take-grant model
• Protection state is a directed graph

      t        r,w
                                    w


                               t         r,w


• Take, grant, create vertex, remove rights

• Here safety is decidable
             Safety questions
• Li et al. 2003, 2005
  – There is a procedure that determines Safety for
    Graham Denning protection states
  – There is a lot of confusion about DAC, HRU‟s
    undecidability result, etc.
  – For SRT (simple RT) that safety questions can
    be answered in polynomial in the number of
    policy statements (the size of the protection
    state)
                       Audit Logic
Standard logical rules (imp_e, imp_i, … ) and:
• SAY: Can use policies someone says to you
    – (Alice says read(Bob, file) to Bob)
    – (Alice says „Shoot Charlie!‟ to Bob)
• REFINE: refinement of policies you can say
• DER_POL: owner of data sets any policy
          b says  to a                            act
   SAY                    a            OBS_ACT                 a
                                              concl (act , a)

          a owns d1 ... a owns d n                   a says  to b
DER_POL                            a   REFINE                         a
              [{d1 , , d n }]                      a says  to b
         Administrative RBAC
• If a role is authorized for certain
  administrative privileges, then implicitly it
  is authorized for weaker ones.
        r1       r3                  r2



        r2                   r1      r3
   a:                   b:
          Suggested reading
• Butler Lampson – Protection
• Harrison, Rizzo, Ullman – Protection in
  operating systems
• optional: Li, Winsborough, Mitchell –
  Beyond proof of compliance: Safety and
  Availability Analysis in Trust management
  (sections 1,2,5)
      Extra assignment: Essay
   (6ECTS, Kerckhoffs‟ students)
• Title and abstract by next Monday
• 5-8 pages, excluding figures, appendices,
  code, formalization of policies
• Peer-review
• Mark is 30% for the review, 70% for the
  paper.
• Final deadline Nov. 17 (can be negotiated)
              Essay subject
• Apply one of the discussed models in a
  medical context
  – introduce the model chosen
  – apply the model
  – discuss pros and cons
• Medical context can be a hospital, or a
  cooperation of hospitals/doctors.
• Trade-off between privacy and availability
              Peer review
• What is the problem?
• What happens if we do not solve it?
• What is the proposed solution?
• Why is it a good solution?
• How does it compare to other approaches?
• Are there possibilities for improvements?
(review form will be on the website)
             EHR scenario info
• US privacy rule for medical information (2002)
  – HIPAA (Health Insurance Portability an Accountability
    Act) google: hipaa summary filetype:pdf
     • Disclosure requires patient authorization
     • Patients have the right to an accounting of disclosure of the past 6
       years.
     • Protection against incidental disclosure but “...does not require that
       every risk of incidental disclosure be eliminated.”

• Ross Anderson‟s papers about UK health systems etc.
• Philips research, DRM (Petkovic)
        about the essay assignment,
if you have trouble finding certain literature
          you can try emailing me

           marnix.dekker@tno.nl

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:5/5/2011
language:English
pages:31