Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
General Access Control Unix Access Control NT Access control
Typology: Study notes
1 / 51
This page cannot be seen from the preview
Don't miss anything!
Elisabeth Oswald and N.P. Smart
Department of Computer Science, University Of Bristol, Merchant Venturers Building, Woodland Road, Bristol, BS8 1UB United Kingdom.
October 26, 2010
Elisabeth Oswald and N.P. Smart
General Access Control
Data structures for access control Unix Access Control NT Access Control
Bell-LaPadula Model
Biba Model
Clark-Wilson Model
Role-Based Access Control
Elisabeth Oswald and N.P. Smart
To enforce access control we can specify I (^) What a subject is permitted to do I (^) What may be done with an object
Traditionally, where objects are usually files, the second approach is taken
In application oriented systems, eg database management, first approach is often more appropriate
Elisabeth Oswald and N.P. Smart
Need to consider who sets the access policy
Two basic operations I (^) The owner of a resource decides who has access. I (^) Such a policy can be called discretionary since access is at the discretion of the owner I (^) A system wide policy dictates who has access. I (^) Such a policy is called mandatory
Most operating systems support idea of ownership of resource.
This is needed to deal with I (^) Policy setting I (^) Systems support operations I (^) e.g. grant, revoke and change ownership
Elisabeth Oswald and N.P. Smart
Next level of complexity are access rights and access attributes I (^) Defined in Bell-LaPadula model I (^) A formal security model covering access control (see later) There are four access rights I (^) Execute, Read, Append, Write These are related to Observe and Alter by: Execute Append Read Write Observe x x Alter x x Files need to be opened for Read or Write access I (^) Preventing conflict between two users Write access includes Observe and Alter I (^) Since write access usually includes read access Most systems do not implement Append
Elisabeth Oswald and N.P. Smart
that we need to indicate what operations certain entities may do on certain resources.
Rights can be defined individually for each subject and object I (^) Cumbersome for large numbers I (^) How do you monitor (easily) that rights correspond to your security policy?
We now consider a number of ways in which access can be defined. Our notation is I (^) S is a set of subjects I (^) O is a set of objects I (^) A is a set of access operations
Elisabeth Oswald and N.P. Smart
To avoid defining a complete table access rights can be kept with the subject or the object. I (^) Saves on space considerably
If kept with subject, every subject is given a ticket (or capability) I (^) Defines a subjects access rights I (^) Corresponds to row in the access matrix
This is an old concept I (^) Often used in real life, less often used in computer-based applications (but Kerberos which we discuss later uses this approach) I (^) Difficult to revoke tickets (should have a life time, need trusted time) I (^) e.g. how do you implement chmod og-w a.out (need to issue new tickets)?
Elisabeth Oswald and N.P. Smart
Access rights are stored with the object I (^) Known as access control list Typical feature of many operating systems
Can be cumbersome I (^) Subjects often placed into groups I (^) Access rights specified for groups rather than individual subjects I (^) How do you find out to which files/resources a user has access? I (^) Need to be checked every time a resources is used
Elisabeth Oswald and N.P. Smart
Some basic properties: I (^) Write does not include read (unlike Bell-LaPadula) I (^) After a machine has booted root (userid 0) gets control, hence has full access to all resources I (^) Hence no audit is possible as root can tamper with audit files (some distributions such as FreeBSD try to fix this by additional attributes such as append-only, etc.) I (^) No notion of delete operation; Handled in Unix by access to directories in same way as files
Elisabeth Oswald and N.P. Smart
ACLs under Unix do not offer the option to store access triples (user, program, file), instead a mechanism based on suid and sgid can be used: I (^) The owner of a program can mark it as suid: program runs with privileges of owner rather than user. sgid does the same for groups.
These mechanisms can lead to unanticipated security holes: invoking a suid root programme can be a way in for an attacker.
Elisabeth Oswald and N.P. Smart
Some basic properties are: I (^) Richer syntax allows for more flexibility in managing access I (^) Less full administrator privileges are necessary I (^) Users and resources can be partitioned into domains to reflect organisational structures
Administrators are still all powerful hence audit without tamper-resistant storage is difficult.
The name of the structure to hide away the ACL details, as well as users, groups, and domains is called Registry.
Elisabeth Oswald and N.P. Smart
Managing access control matrices and ACLs can be very complex Other methods are needed
One way is to divide subjects and objects into levels I (^) e.g. unclassified, confidential, secret, top-secret The security level of a subject is its clearance
The security level of an object is its classification
If levels are strictly ordered then access is permitted if and only if the clearance is greater than or equal to the classification.
Elisabeth Oswald and N.P. Smart
Now we give a more technical description of Bell-Padula.
A Lattice is a set L equipped with a partial ordering ≤ I (^) Every two elements a, b ∈ L has I (^) A least upper bound a ∨ b I (^) A greatest lower bound a ∧ b A finite lattice must have top and bottom elements
If a ≤ b, we say that b dominates a. I (^) The bottom level dominated by all others in a system is a low security level I (^) The top level which dominates all others is a high security level
Elisabeth Oswald and N.P. Smart
Lattices were proposed to model multi-level security (MLS) policies since they allow an ordering of security levels:
Given two objects at different levels a and b there is a minimal level a ∨ b needed to access both a and b
Given two subjects at different levels a and b there is a level for an object a ∧ b which must be readable by both.
Elisabeth Oswald and N.P. Smart
