Policies And Models¶

Multilevel security (MLS)¶

Form of mandatory access control (1970s)
- Policy from the Department of Defense
- Protection system consists of multiple levels of security
- Later formalized by Bell-LaPadula
Goal: Prevent information leakage
Information flow can be vertical and horizontal
- Vertical: Across different security levels
- Horizontal: Across different objects/subjects inside a security level
Policy
- Prevent subject from reading data that is more secret
- Prevent subject from writing data to less secret objects
Implementations:
- Multics
- Scomp

Design principle for information security (less formal)
Saltzer (1975)
A Protection mechanism should force every process to operate with the minimum privileges needed to perform its task.
See also:
- Principle of Psychological Acceptability
  - Interface should be signed for ease of use. Users should automatically apply protection mechanisms correctly
- Principle of Fail Safe Defaults
  - Unless a subject is given explicit access to an object, it should be denied access to that object.
Implementation
- Goal: Determine required permissions of a program
- Interactive policy generation
  - systrace: Monitor used syscalls (requires benign environment, see kRazor)
  - audit2allow: SELinux command adding denied permissions to policy
Advantages
- Functional definition of tasks (e.g., backup software should only perform backup-related tasks)
- Unnecessary permissions lead to problems (see Confused Deputy Attack)
Disadvantage
- Task permissions can conflict with security (required permissions but insecure)
- Hard to determine whether a permission makes system insecure
Verification
- No verifiable because it is based on functionality (undecidable)

Focus: Authorize the flow of information between subjects and objects (read + write)
Models:
- Secrecy:
  - Denning’s Lattice
  - Bell-LaPadula (MLS)
- Integrity:
  - Biba
  - LoMAC
  - Clark-Wilson
- Secrecy/Integrity:
  - Caernarvon
  - Chinese Wall
Advantage
- No false negatives (attack requires illegal information flow, which is prohibited)
- Defines data security requirements
- Defines functional security requirements
Disadvantage
- Function may conflict with security (e.g., secrecy)
- Hard to find exceptions (required permissions for function but permission is currently denied)
Verification:
- Policy is based of security
- => Verifiable

Definition (BSI):
- “Korrektheit (Unversehrtheit) von Daten und der korrekten Funktionsweise von Systemen”
Software integrity
- Software behaves as specified (do not depend on low-integrity input)
- Static: Verified source code
- Dynamic: Software stays in allowed states
- Data integrity: Assurance of accuracy and consistency of data over its entire life-cycle
- Dependency data integrity and software integrity
  - Accuracy
  - Reliability
  - Consistency
What is necessary to enforce integrity?
Types of integrity (bias):
- Functional: Principle of Least Privilege
- Security: Information flow
Important: Design a mandatory protection system for integrity (covering function and security)

Biba (1975)
Information Flow Model
Focus: Integrity (not confidentiality)
- Do not depend on data from lower integrity principles
- Information flow: Only from high integrity to low integrity
- Characteristic phrase: Read up, write down
Application:
- Military
- Firewalls
Read from higher integrity source
Write to lower integrity source
Practical use: Integrity not realized (too restrictive)
Problem:
- Biba prohibits information flow from low to high
- e.g., read from network socket
- Solution 1: Use fully-assured guards (application-specific code validating the input)
- Solution 2: Change integrity level (see LoMAC)

Variation of Biba model
Information Flow Model
Idea:
- Subjects/objects get integrity label
- Label can be changed
- Allow reading from lower integrity objects
Basis: Lattice of integrity labels
Reading from lower integrity objects
- Set subject label to object label (transitions)
- Definition of subject label: Set of accessed objects (minimum integrity of accessed objects)
Writing to higher integrity object
- Denied
Self-revocation
- A process of high integrity reads a lower-integrity file
- Integrity level of reading process is reduced
- Problem: Process can’t write to its former created files/lots of programs running at low integrity
- Solution:
  - Add minimal integrity level
  - i.e., range of allowed integrity levels for a subject
  - Realized in IX System

Clark/Wilson (1987)
Application in finance sector
Goal:
- Define integrity for commercial systems (instead of military)
- Define how data integrity is ensure in a system working with this data
- Adapt to double-bookkeeping in accounting
Basics
- Basic unit is a transaction
- Transactions lead from one consistent state to another
- Integrity is based on the control of a transaction
- Principle of Separation of duty: Certifier and invoker of a transaction are different
System
- User may modify as CDI iff he can access the TP and the CDI and the TP may change the CDI

Constrained Data Item (CDI):
- High integrity data inside the system
- Must be kept valid
Unconstrained Data Item (UDI):
- Low integrity data which is not certificated (e.g., user input)
Integrity Verification Procedure (IVP):
- Program that certifies that the CDIs are valid
- High integrity code
Transformation Procedure (TP):
- Take CDI or UDI an create a new CDI
- High integrity code

Integrity constraints:
- CR1: IVP must ensure, that all CDIs are valid
- CR2: TP must transform a set of CDIs from one valid state to another
Limit users/TPs that may access CDIs:
- ER1: Only certified TPs may change certain CDIs (system keeps list)
- ER2: Only authorized users may execute a certain TP on a certain CDI
Authentication:
- CR3: List must be certified under the separation of duty
- ER3: System must authenticate every user attempting to run a TP
Auditing:
- CR4: TPs must append information to log files for reconstruction
Administration:
- ER4: The certifier of a TP may change the list of entities associated with that TP only
- CR5: TP taking a UDI as input must either upgrade the UDI to CDI or discard the UDI (self-guard)

Valid information flows are not that different from Biba/etc.
Concepts of Clark-Wilson are closer to current best practice
Problem with current OS:
- Not writing IVPs
- Not certifying TPs/CDIs
- Programmers do not ensure that UDI are transformed

Philosophy: Assume we can distinguish CDIs/UDIs
Idea: Ensure that programs only receive UDIs where the programmers are prepared to handle untrusted inputs
Programmer partitions date into CDIs/UDIs
Program defines entry points for UDIs (either discard or update)
System calls with UDI data are only allowed in the entry points (no further call may contain UDI data)