1. Access Control Models EN
Lecture Notes
Fall 2016

2. Access Controls Once you are authenticated, what can a principal do?
Access controls can be implemented at various levels
Anderson focuses on machines rather than networks
Hardware
O/S
“Middleware”
Application
Access Controls go beyond this, of course:
Networks (Firewalls, etc.)
Physical security (Rooms, etc.)

3. Hardware Level Access Control
Controlling programs
“Protection problem” – Keep programs from interfering with each other
“Confinement problem” – Keep programs from using unauthorized channels
Memory protections – Segment a program’s memory
Problem – Low level program communicating with higher-level program
Trusted computing
Lock memory even against administrator control
Right now, if you’re root, you could literally re-write the O/S in memory
Ensure boot-strapped, security critical code

4. OS Additional Memory Protections
These are new features in OS-X from the past few years
Address Space Layout Randomization:
Randomly laying out memory makes buffer-overflow attacks harder
Application sandboxing

5. OS Access Controls
“Read-Write-Execute” are pretty familiar permissions these days
Individuals, Groups, Roles
“Access Control Lists” (ACL)
Basically, per resource, what each identity can do
Current implementations:
Please read carefully about “setuid” and how setuid root is bad
Capabilities:
“rows” in the access control matrix instead of “columns”
I think Anderson’s view is simplistic

6. Capability Argument System Disable Capability Façade to File A File A
Opponents of capabilities argue that you cannot change a file’s status
They just don’t understand capabilities
System Disable
Capability
Façade to File A
File A

7. Middleware (e.g., Databases)
Middleware often has its own access controls
For example, a database has its own login/password mechanism
One security problem is mapping authentication from the App to the Middleware

8. Sandboxing and Virtualization
From a security perspective, these two ideas are more-or-less the same
Virtualization has stronger guarantees because it usually involves the operating system
Sandboxing and Virtualization cut across Anderson’s layers
Some elements from hardware, O/S, Middleware, and App
PERSONAL OPINION:
I think the future of security is here.
You could have your browser run in a virtual O/S
PLAYGROUND: How will you protect yourself from untrusted code?

9. Application Access Controls
This is the hardest place to have access controls
Applications have the least enforcement capabilities
Usually, for stronger protections, Apps have to rely on lower-level mechanisms

10. Mandatory Access Control
The basic idea is that there are different classifications on the data
For example, secret, top secret, etc.
The data cannot be accessed except by a principal with a clearance as high as the data
This is NOT like *nix file permissions
Policy is administered centrally by a security officer
Users cannot grant access to a file (no chmod r+w)
*nix is an example of “discretionary access control” or DAC
Enforced security independent of user actions is the essence of MAC

11. Security Policies Again
Remember our early lecture: threat model, security policy, security mechanisms
Security policy is often the element most poorly executed
It needs to express clearly and precisely what needs to be protected
Unfortunately, it is often a collection of “vapid” statements
For a new product, you may need to design from scratch
But, many times, you can choose from existing policies
The hard part becomes choosing the right one

12. Bell-LaPadula (BLP)
Design emerged from military document classification
Enforces two properties
Simple Security Property: No Read Up (NRU)
*-Property: No Write Down (NWD)
The *-property was the big innovation of BLP. It assumed trojans and buggy code!
This is a well defined security policy
It is relatively easy to determine if the mechanisms enforce the policy
If it’s the right policy it works great!

13. Criticisms of BLP
If the security officer can “temporarily declassify” all of the protections go away
Strong tranquility: security labels never change during operation
Weak tranquility: labels never change in a way that violates security policy
The idea here is “least privilege”. Even if you have TS, start at unclassified
As you access info that is higher, your level increases
The system can get fragmented into pieces that can’t communicate
Also, what do you do with an App that has to straddle?
A document editor used to redact a TS document to Classified
Doesn’t deal with creation of subjects or objects

14. Type Enforcement Variation
Expands on BLP by having subjects assigned to domains and objects to types
A domain/domain matrix defines how subjects interact with each other
A domain/type matrix defines how subjects interact with objects
SE linux is built on this idea, but subjects and objects are assigned types
The matrix is pairs of types and the security properties associated
This is great, but it leads to a “state explosion” that is hard to reason about
SE linux also includes a simpler MLS policy to help maintain security

15. Role-Based Access Control (RBAC)
User’s permissions aren’t based on names, but on their role
This allows for more fine-grained controls on users
User A acting in role 1
User A acting in role 2

16. The Biba Model Upside-down BLP You can only read up and write down
The goal is integrity not confidentiality
Partially used in Vista. Uses the NoWriteUp.
Most files are “medium” or higher. IE is “low”
So, things downloaded can read most files, but not write to them!
This was the first formal model of integrity
Struggled in real-world because of the exceptions and straddling issues

17. Misc Anderson is full of additional MLS details Historical MLS systems
Future MLS systems
Vista
Virtualization
You should review these for your own learning, but not on the test
The data pump, however, might be useful to you in PLAYGROUND
If you do MLS, you can pump data from low security to high
But if it’s one way, how do you do acknowledgements?!

18. What Goes Wrong in MLS? Composability is always hard
Anderson gives an interesting xor example where feedback results in high data getting released low
The example is very academic but illustrates the problem of composition
Composition, remember? The Google break? Cross-site Scripting?
It’s easy if there is no feedback, but feedback happens more often than you think
Variant: Cascading, or combining two security systems to break a policy
Covert channels that allow High to signal to Low
Polyinstantiation – High and Low both try to create a file of the same name

19. Multilateral Security
In commercial projects, the bigger problem is not data up and down, but across
The marketing department should not have access to R&D
The problem is, again, centralization
It makes a bigger target
AND give more people access to it…

20. The Lattice Model
Military uses multilateral security too adding code-words to secrets
In WW2, the allies broke the enigma enciphering machine
This information was so sensitive, that only a few people could have access
This set of people, though small, covered different classifications
The code word “Ultra” was applied
People with this label could not be placed in any area with a risk of capture
Lattice is classifications + code words
Same as BLP for up and down
But zero information moving between “compartments”

21. The problem of Sharing
The Lattice model does a good job of preventing information flow
But what to do when information needs to flow?
You can create yet another compartment, but this leads to label explosion
You can rely on a trusted “guard” that allows information to flow
But this increases the amount of “trust” in the system
This system breaks regularly

22. Chinese Wall Model
Derived from rules in banks to prevent conflicts of interest
It begins with a free choice: choose A or B
But not both!
This last part is the Mandatory component
It has some great properties, but often requires manual enforcement

23. Inference Information sharing often involves some kind of “scrubbing”
In MLS, a report is redacted before moving down a security layer
In Multi-lateral security, data is often anonymized
The problem, of course, is inference
People can often be identified by their medical records even with names removed
And, of course, we’ve seen this with AOL and Google

24. Inference Control
Characteristic formula – the query instructions to get some set
Query set – the set produced by a characteristic formula
Elementary set – the smallest set produced by the AND of all available fields
Sensitive Statistics – stats that deanonymize information:
For example, if the set is too small, than we’ve identified an individual by attributes

25. Query Size You can limit how small a result is from a query
But you also have to worry about returning N-1!!
Also, you have to deal with using multiple queries to get a smaller than N intersection

26. Custom Trackers A special formula that identifies an individual
For example, if there is only one female professor
Determine her salary by asking:
Average salary of professors?
Average salary of male professors?
Solutions?
Limit the number of attributes that can be used on a query
Trying to audit a user’s queries (track a user so they can’t get info by intersecting)
Doesn’t work really. Too complex and doesn’t deal with collusion

27. Active Attacks Attacker can insert and delete records in the database
Allows them to bypass query size controls for example