## 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

### Principle of Least Privilege
- Design principle for information security (less formal)
- [Saltzer (1975)](https://dl.acm.org/doi/pdf/10.1145/361011.361067?download=true)
- *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)

### Information flow models
- 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

### Integrity
- Definition ([BSI](https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/vorkapitel/Glossar_.html)):
	- "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)

### Information Flow for Integrity

#### Biba model
- 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)

#### Low-Watermark Mandatory Access Control
- 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 Integrity Model
- 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

###### Constructs
- *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

###### Certification and enforcement rules
- 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*)

###### Results
- 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

###### Clark-Wilson Lite
- 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)