EN Lecture Notes Spring 2016 ACCESS CONTROL MODELS

MANDATORY ACCESS CONTROL MAC is a form of “multi-level” access controls. 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

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

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!

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

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

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

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

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?!

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

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…

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”

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

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

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

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

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

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

ACTIVE ATTACKS Attacker can insert and delete records in the database Allows them to bypass query size controls for example