## Exercises

### Programming exercise

#### 01 Namespaces
- Process
	- Concept for an executable
	- Gets virtual memory (mapped to physical)
	- Share resources
- Isolation
	- Virtual machines
		- Isolate complete OS
		- Own kernel and applications
		- Isolation enforced by Hypervisor
		- Disadvantage: Heavy weight (kernel)
	- Container
		- Isolate processes
		- Use namespaces for access
		- Re-use host kernel
- Linux Namespaces
	- Abstraction of resources (box holding resources)
	- Process belongs to one namespace per type
	- Create new namespace: `unshare`
	- Namespaces
		- Unix Timesharing System (hostname, domain)
		- IPC
		- PID (process number, PID 1 in container)
		- User (isolate user/group IDs, use mapping to host)
		- Mount (isolate mount points, change root)
- Change root
	- `chroot`: Not for security reasons, only pathname resolution
	- `pivot_root`: Securely change root (then unmount old root)
- Workflow:
	- Create namespaces
	- Mount new file system
	- Change user/group IDs
	- Mount special files (`dev`/`tmp`/`proc`)
	- Change root
	- Fork container process
	- Set hostname
	- Execute entrypoint


![](images/namespaces.png)

#### 02 Securing container
- More isolation:
	- Environment variables (e.g., `USER`, Tokens, Paths)
	- Scheduling information (`/proc/sched_debug`)
- `init` process
	- PID 1
	- Collects zombies (child whose parent died)
	- Container root process is `bash` (doesn't collect children)
	- Use container-aware init process (e.g., `tini`, `dumb-init`)

##### Resource restriction
- Isolate resources
- `nice`: process priority
- `setrlimit`:
	- Restrict resources for process and children
	- But consumption is not accumulated
	- Child may use as much as parent
- `cgroups`: 
	- Fine-grained, complex limitation
	- Requires root
	- Uses controllers (manage groups using directories)

##### Syscall restriction
- Filter syscalls
- `seccomp`
- Based on Berkeley Packet Filters
- Library `libseccomp` (easier to use)
- Features
	- Masking of arguments
	- Creating black- and whitelists

##### Capability restriction
- Linux 2.2 introduced `capabilities`
- Each thread has sets of capabilities (basically bitmasks)
- Sets:
	- Bounding set `$ B $`
		- Superset for capabilities a thread can add to inheritable and permitted sets
	- Permitted `$ Prm $`
		- Capabilities a thread can have
		- Superset for the effective capabilties
	- Effective `$ Eff $`
		- Capabilities a thread has (used for permission checks)
		- File capability is single bit
	- Inheritable `$ Inh $`
		- Not preserved across `execve` (non-root)
	- Ambient `$ Amb $`
		- Preserved across `execve` (non-root)
- Roles:
	- Child process `$ C $`
	- Parent process `$ P $`
	- File `$ F $`
- Rules
	1. `$ B\supseteq C_{Inh} $`
	2. `$ B\supseteq C_{Prm} $`
	3. `$ C_{Prm}\supseteq C_{Eff} $`
	4. `$ C_{Prm} = (P_{Inh} \& F_{Inh}) | (F_{Prm} \& B) $` (6.)
	5. `$ C_{Eff} = F_{Eff} ? C_{Prm} : C_{Amb} $`
	6. `$ C_{Amb} = (\text{file is privileged}) ? 0 : P_{Amb} $`
	7. `$ C_{Prm} = (P_{Inh} \& F_{Inh}) | (F_{Prm} \& B) | C_{Amb} $`
	8. `$ C_{Eff} = F_{Eff} ? C_{Prm} : C_{Amb} $`
	9. `$ C_{Inh} = P_{Inh} $`
- Drop capabilities
	- `libcap`
	- Drop specific capabilities
	- Problem: Inside container we are root 

#### 03 SGX SDX
- Use wrapper code `edger8r`
- Enclave metadata file
- Enclave description file
- `enclave_u`
	- Untrusted side (call Untrusted Runtime System)
	- Marshal arguments
- `enclave_t`
	- Trusted side (called from TRTS)
	- Unmarshal arguments
- Untrusted Runtime System
	- Transition into enclave
	- Provides ECALLs
- Trusted Runtime system
	- Provides OCALLs
- Libraries
	- No unsafe calls
	- No system calls
	- Use SGX libraries



### Paper analysis

#### Evaluating Software (In)Security
- [Jain et al. (2017)](https://doi.org/10.1145/3102980.3102991)
- Topic
	- Measure software security/TCB complexity
	- Changing code base increases risk for new bugs
	- Which metrics are useful?
	- Goal:
		- Prevent security issues
		- Prove absence of bugs
- Current standard
	- Formal verification: Too complex
	- Lines of code: Unreliable 
		- Lines of code weakly correlates with vulnerabilities
		- Bug does not imply vulnerability
	- Testing
		- Auditing prevents bugs
		- Unit tests find obvious bug (not necessarily vulnerabilities)
	- Bug finding tools
- Contribution: Features of code to train a classifier (static analysis)
- Propose metrics/features:
	- Lines of code
	- Common Vulnerability Scoring System (CVSS)
	- Radial Attack Surface Quotient (RASQ)
	- Number of functions/variables
- Classes to predict:
	- Network attacks
	- Buffer overflows
- Dynamic analysis more effective
	- Detect vulnerabilities in runtime
	- Monitor program behavior
	- Advantage if code base is inaccessible
- Discussion:
	- Feature set provided but no classifier


#### Kernel Attack Surface Reduction (kRazor)
- [Kurmus et al. (2014)](https://doi.org/10.1007/978-3-319-08509-8_12)
- Problem:
	- 90 % of kernel functions are not used by average network daemon
	- Unused kernel functions mean unnecessary large attack surface
- Contribution: Limit attack surface by reducing number of kernel functions at run-time (kRazor)
- Definition *attack surface*: 
	- Subgraph of kernel call graph
	- Entrypoints are accessible to adversary
- Approaches:
	- Static:
		- Micro-kernel (lack of compatibility, e.g., MINIX 3)
		- Kernel specialization (remove sys-calls from kernel, re-compile kernel for application)
	- Dynamic:
		- System call monitoring
		- System-call-based process sandboxing (whitelist system calls, kRazor is generalalization of this)
- kRazor:
	- Run-time
	- Complete mediation (syscalls are objects)
	- Add hooks to each syscall
	- *quantifiable* + *non-bypassable*
	- Learn set of system calls used by application
	- Create set of allowed kernel functions (expand by using related functions, e.g., `read` and `write`)
	- Option for violations:
		- Kernel Oops
		- Logging
- Metrics for attack surface:
	- LOC
	- Cyclomatic complexity
	- CVE-based (1 if function has security vulnerability, 0 otherwise)
- Discussion:
	- Least Privilege Policy
	- Problem: No guarantee that all system calls are traced (edge case)
	- No statistics in prevented attacks



#### TrustVisor
- [McCune et al. (2010)](https://doi.org/10.1109/SP.2010.17)
- Related lectures: SGX
- Provide isolation for security-sensitive code parts (PALs)
- TrustVisor is a hypervisor
- Features:
	- Code integrity (memory region is checked)
	- Data secrecy (memory is encrypted)
	- Data integrity
	- Execution integrity
- Marshal parameters when call enters a PAL
- Split code into sensitive and non-sensitive parts
- Use Dynamic Trust for Measurement (hardware component)
	- Chain of Trust
- Emulate TPM for each PAL
- Memory encryption is not possible, use memory isolation
- Trap into hypervisor if PAL is accessed


#### From L3 To seL4
- [Elphinstone et al. (2013)](https://doi.org/10.1145/2517349.2522720)
- Related lectures: Security Kernels, VMM
- seL4 is security-microkernel
- Microkernel principles:
	- Minimality (and no policy in kernel)
	- IPC performance
	- Real-time computing (?)
- Development since L4:
	- Synchronous messaging replaced (support multi-threaded application)
	- Physical registers to virtual registers (improve portability)
	- Long IPC removed (could trigger page faults)
	- Thread IDs replaced by *port-like endpoints* (improve confidentiality)
	- IPC timeouts restricted to 0 (poll) or *infinity* (block) (adapt to practice)
	- Communication control (*chief-and-clans*) remove (contradicting goal of policy-freedom)
- Problem of scheduling:
	- Scheduling often implemented in kernel
	- Contradicts goal of policy-freedom
	- Often used: Hard-priority round-robin (fixed time-slices)
	- Scheduling in user-space too slow (bottleneck is IPC)
- Minimality
	- Important
	- Formal verification is easier with minimality
	- But it influences design decisions (multi-threading, complex scheduling, standard calling convention)
	- Authors do not think performance suffers from the new design decisions




#### Graphene-SGX
- [Tsai et al. (2017)](https://www.usenix.org/system/files/conference/atc17/atc17-tsai.pdf)
- Related lectures: SGX


#### Hardware Is The New Software
- [Baumann et al. (2017)](https://doi.org/10.1145/3102980.3103002)
- Related lectures: SGX


### Lecture Questions
#### 01 Introduction
- What are the problems with adversary code on your machine?
- What can an adversary do? 
- What can you do to avoid executing adversary-controlled code? 
- What is the problem with running code from benign sources? 
- How would "good" code look like? 
- Who may be responsible for software and systems security in computing environments?

#### 02 Threats & Security Principles
- Why is Protection State insufficient to enforce security? 
- What do we need to achieve necessary controls? 
- How do we know the policy expresses effective goals? 
- How do we know the enforcement mechanism will enforce policy as expected? 
- How can you use an MPS to control use of bad code? 
- How can you use labeling state to control bad code? 
- What defines correct code?
- What defines correct policy?
- What about objects created by these processes? 
- How can you use labeling state to prevent good code from going bad? 
- What if good code needs to access some adversary-controlled resources? 
- How do we achieve this change with the MPS? 
- Is it possible to launch processes with more permissions than the invoker with MPS? 

#### 03 Multics
- „If people just used Multics, we would be secure. UNIX and Windows are insecure.“ What is the basis for these statements?
- Does Multics implement a Mandatory Protection System enforced by a Reference Monitor? 
- Does Multics satisfy the evaluation criteria? 
- What were the security goals for Multics? 
- Are brackets a Mandatory Protection System? 
- Multilevel Security a MPS?

#### 04 LSM
- How do we add MAC enforcement effectively to a commercial OS?
- What is required to be a secure OS? 
- Which Linux data types are sensitive? 
- What to do about object creation before the security module is loaded? 
- How do we know LSM implements complete mediation? 
- How is LSM code protected?
- How is LSM data protected? 
- Where to exactly place the hooks? 

#### 05 Integrity
- What is data integrity?
- What do we need to do to ensure data integrity? 
- What do you expect for integrity of software? 
- How does software integrity impact data integrity? 
- How to compute least privilege? 
- Can we use it to verify a policy is secure? 
- What do we do if a system needs an information flow from low integrity to high? 
- Assured Guards: What does “fully assured” mean? 
- What could you do to avoid self-revocation? 
- But shouldn’t programs at least know where they expect to receive UDIs?

#### 07 Security Kernels
- What are the advantages of such an approach?
- What are the limits of verification? 
- Why is Scomp appropriate to support such an application? 
- [Drivers in user space] how is this possible in Scomp?
- [Complete Mediation] For files? For mail data? What about DMA operations? 
- Why are systems like Scomp not the norm?
- Why are drivers a problem? 
- How do we reduce such problems? 
- Can we somehow fix drivers? 
- What exactly does an MMU do?
- Who does Mediation?
- Are they all reference monitors? 
- Does this approach satisfy reference monitor concept? 
- Does it implement a MPS? 
- So why don’t build systems with such a design? 
- What could be transferred to current systems?

#### 08 VMM
- Do these work for modern OSes? Are there alternatives?
- How does VM isolation differ from OS isolation? 
- What are the trust model issues when comparing Type I and Type II? 
- How does a VM System improve the ability to achieve reference monitor guarantees? 
- What components constitute the VAX VMM reference monitor? 
- How is the protection state modified? 
- How do we implement a reference monitor and a validation mechanism for theses systems? 
- At what granularity control should be enforced? 
- How do we configure access control for containers? 
- Can we use VM isolation to prevent compromise of applications by malicious OS?