Two Types of Access Control
-Discretionary:
--The user decides who has access to the objects he creates.
--Everything we have talked about so far.
-Mandatory:
--The user does not always have the ability to determine who has access to the objects he creates.
--Typically the accessibility is determined by a central authority.
--The accessibility of an object depends on what was used to create it.
--Examples:
---A doctor does not have the right to reveal patient information even though he wrote the chart.
---The military determines who can see "Top Secret" files based on their security clearance, not by who wrote the file.
Multilevel Security
-Each data object is assigned to a security level (one of multiple) rather than each user.
-Each security level is usually based around some group of users or some type of resource.
-The Security levels are generally organized into some form of a hierarchy.
-A security policy called Information Flow is based on multilevel security.
--It is generally more secure than access control.
--It regulates how information moves throughout the entire system.
--The intuition behind it is that secure information should not flow into less secure locations.
--It is a social and system practice.
Example: Military Security Policy
-Classification involves security levels and compartments (topics of data).
-Classified information should not be leaked to unclassified files (in other words, data can't flow against the classification levels).
-Personnel and data are grouped into classes based on their security rank and compartment.
-An ordering of the classes is created by using a dominance relation.
--Class 1 is said to dominate class 2 if and only if the rank of class 1 is less than or equal to the rank of class 2 and the compartment of class 1 is a subset of the compartment of class 2.
--So if class A is dominated by class B, then class B is at a higher security level then class A.
-Information is only allowed to be shared with something higher in this ordering.
-To enforce this they use a Bel-LaPadula Confidentiality Model.
--This model is based on the policy "No read up, No write down".
--Members of a certain class are not allowed to read data that is at a higher security level because this would give them direct access to secure information.
--Members of a certain class are also not allowed to create an object that is classified as a lower security level class, because this would allow them to use secure information in the object and make it available to people of a lower security level.
Multilevel Security Policies
-Security levels usually form a "join semi-lattice".
-This implies two properties about the security levels.
-First, there is an ordering, such as dominance, on the security levels.
-Second, for any pair of security levels (say, L1 and L2) there is a "join" operation.
--This is defined as follows: L1 join L2 is a label in the lattice such that:
---L1 is less than or equal to L1 join L2 and L2 is less than or equal to L1 join L2.
---If L1 is less than or equal to L3 and L2 is less than or equal to L3, then L1 join L2 is less than or equal to L3.
--L3 is considered an upper bound of L1 and L2.
--L3 is considered the least upper bound (LUB) if some level L4 is an upper bound of L1 and L2, and L3 is less than or equal to L4.
-An object is placed in a level based on a classification function, C, which maps an object to a lattice.
-If some object O is created form objects O1, O2, ...On, then C(O) = C(O1) join C(O2) join ... join C(On).
-When an object is created you want to give it the lowest rank (or LUB) allowed by all of the sources of the data.
Implementing Multilevel Security
-There are two different methods of implementation.
-Dynamic:
--All values in memory are tagged with their security level.
--Operations must propagate security levels.
---For example: (L1 integer) + (L2 integer) = (L1 join L2 integer)
--Tags must not be allowed to be modified.
--This is an expensive implementation.
--This is also approximate due to the fact that tags will eventually move up the lattice because after the computer touches something with a high security level, everything it touches afterwards will be required to be labeled as that high security level.
-Static:
--Program analysis
--It may be more precise and have less overhead.
-From this we learn that Information Flow policies cannot be implemented solely by a reference monitor because problems arise from implicit flows.
Information Flows through Software
-There are two types of flows in software.
-Explicit flows:
--This occurs when secret data tries to get assigned to a public variable.
--This will not be allowed because it would allow the public to see secret data.
-Implicit flows:
--An example of when this occurs is when a variable holding secret data is used as a branch condition.
--While the secret data may not be available directly to the public, some information about it could be inferred.
--For example if one of two public variables is set to 1 depending on what branch is taken, the public will be able to learn about the range of the secret data based on what variable is set to 1.
--Similarly, information about the secret data can be inferred if the program stops when this is encountered because the public can see which branch the program was in when it stopped.
--This is why Reference Monitors cannot enforce information flows on their own.
Perl's Solution for Integrity
-The problem that is being focused on is that the source of data needs to be tracked.
-Perl offers taint checking mode as a solution.
--It tracks the source of data (classified as either trusted or tainted).
--It ensures that tainted data is not used in system calls.
--Tainted data is able to be converted to trusted data through pattern matching.
--This only focuses on explicit flows and does not check for implicit flows.
SELinux
-SELinux stands for Security Enhanced Linux system.
-It enforces the separation of information based on the information and integrity requirements.
-For major subsystems of the kernel, it is mandatory that access control is incorporated.
--This limits the tampering and bypassing of application security mechanisms.
--It also confines the damage caused by malicious code.
SELinux Security Policy Abstractions
-SELinux was built by the NSA.
-Type enforcement:
--Each process is associated with a domain.
--Each object is associated with a type.
--Configuration files specify which domains can access which types and which transactions and interactions are allowed between domains.
-Role-based access control:
--Each process is given a role so that they are all separated into system and user processes.
--Configuration files specify which roles can enter which domains.
Two other MAC policies
-The "Chinese Wall" policy.
--Objects are classified into different "conflict classes".
--If a subject accesses an object that is in a particular class, it is denied access to every object not in the same class.
--The policy can change dynamically.
-"Separation of Duties":
--Responsibilities are divided among subjects.
--An example: Bank auditor cannot issue checks.