Josiah's Secure Computing Systems Notes

Usually refer to the “keeper of the keys” as the “Trusted Computing Base"

Usually the OS (or Hypervisor)

TCB must be tamper proof, un-bypassable, and vulnerability free (partially unrealistic)

TCB response for: Authentication, Authorization, and Auditing

TCSEC defined a set of criteria (followed by Common criteria) which defined a set of expectations.

Trusted Policy Module (TPM) is a HW-based root of trust that does platform measurement, attestation, etc.

Standard owned by TCG

Principles of systems security

Security cost must be appropriate with threat level and asset level (defender vs. attacker cost curves)

Should be easy enough to use

System should be as simple as possible (economy of mechanism)

Corollary: Don’t rely on obscurity

e.g. TCB —> Hypervisor

Least privilege and separation of privilege

HW necessary component of separation (TCB). We have to trust it (simplification)

Unit of protection: Address space + Privileged instructions

Modes: Real, Protected, Long/Flat

Logical Address Space per Process —> Physical Address map required

Address space divided into logical units (segments). e.g. code, data, stack, etc.

Segment further divided (pages). Pages are fixed size (e.g. 4KB in 32bit x86)

Logical Address: (Segment number, page number, page offset)

Global and local segment descriptor tables (GDT, LDT) store segment mappings

Page table for pages, etc.

Address Translation:

Logical Address = (segment number, displacement)

Physical = *(SGTBR + STE * STE Size) + displacement

SGTBR = Segment Base Register

STE = Segment Table Entry # (segment number)

Complicated by segment selectors and paging

Each segment gets protection bits (representing protection level or DPL). 0 - 3 (0 most privileged)

DPL: Descriptor protection level

Current Protection Level (CPL)

DPL of the code segment being executed

Requestor Privilege Level (RPL)

Specified in segment selector

Check: Max (CPL, RPL) <= DPL of target

Why RPL? To avoid privilege execution (kernel executing code on behalf of an application)

Page level Protection

PPL (page protection level) of 0 (privileged) and 1 (non-priv)

CPL with 3 can only access PPL 1

Read-write protection

Execute disable protection

Can combine segment and page protections

Changing Privilege Level

Specify code segment to access

Specify privilege level required for *caller*

Entry point for procure in called code segment

Number and size of parameters when stacks are to be switched

Intel now has SYSENTER & SYSEXIT (SYSCALL & SYSRET)

Previously used interrupts

Privileged Instructions

Can only be executed at CPL 0

e.g. LGDT, LLDT, MOV (control registers), HLT, etc.

Attack examples including row hammer, kernel rootkits, etc.

Virtualization & Security

Assumes IO instructions are privileged (this wasn’t always true)

VMM Types: Type 1 (Hostless) Type 2 (Hosted)

Simplicity argument probably only applies to type 1

Green & Red Virtual Machines

Green VM: Machine with “good” apps. Red VM: Machine with malicious apps.

VMM provides isolation between apps / operating systems.

Transparency: VMM must provide execution environment which is identical to underlying physical machine (ignoring some performance degradation)

Complete Mediation: No way to bypass VMMs control on physical resources

Efficiency: Most VM instructions should execute natively

Requirements for Type 1 VMM

Non-privileged instructions should be executed natively (in the same way).

Privileged instructions must be trapped and mediated

Instructions that reference mode of VM and state of physical machine

Instructions that read/write sensitive registers or memory

Instructions that impact memory protection system and address translation

OS Aware it is not ring 0: Para-virtualization. Requires changes to OS

Ring concept: VMM (Ring -1) —> Ring 0 (“root”) —> Ring 3 ("App Space")

Intel SGX: HW-protected enclave that protects data in an address space that can’t be accessed including the hypervisor

Goal: Easy for correct user and hard for attacker

User Friendly: High True Positives. Low False Negatives.

Strong: Zero False Positives

System knows something specific about a user

Something you know —> e.g. Passwords

Something you have —> e.g. Physical token, phone

Something you are —> Fingerprint, retina scanner

System asks you to demonstrate this

Multi-factor refers to using multiple… factors

What counts as “hard”? See: guessing entropy

AuthN indicates who the requester is. AuthZ indicates what they can do.

DAC is a policy set by the owner. MAC is a policy set by the system

Access Control Matrix maps people to resources

Can be represented via ACLs or Capability lists

Unix: ACLs but with fast access for r/w operations

Owner, group, and others could have r, w, x permissions

Check on open(F, mode) call only which returns a file descriptor fd

Read and write calls use fd

Exists a TOCTOU vulnerability

Windows includes concept of “Negative access rights"

Hydra uses a “capabilities” system for everything

MAC addresses problems with DAC

Information Control Problem

Alice can never be sure that sensitive data she shares with Bob will not be further shared with others

Bob can make a copy of Alice’s file for which he has read access and share this new file containing her data with others

Sharing of information user U creates may be constrained by his or her organization

Defense and intelligence agencies limit how info can be shared

Labels represent sensitivity, etc.

Label comparison defined via lattice structure (partial order)

Subject S can read object O if the label of S dominates the label of O

Subject S can write object O if the label of S is dominated by the label of O

RBAC defines what roles users can assume AND what permissions are given to roles (instead of users directly getting permissions)

Groups are a collection of users. Different than a role.

Roles size = R * (U + O)

As R —> 1, size —> U + O

BLP: Provides Confidentiality

Biba: Provides Integrity

SELinux

Mandatory access control helps control data, but few OSes support by default.

SELinux is a system that adds support —> Redhat, other Linux distress, SEAndroid, KNOX

Basis of SELinux is the Linux Security Module

Loadable kernel module to separate enforcement from policy

SELinux Security Context

Accès checked after DAC
Policy configurable
Context defined as User:Role:Type:Range

Enforcement

Access: allow source target:class operation
Inheritance: Child inherits parent. In the context of files, inherit from parent directory
Transition happens through execution
Not allowed to override

Multi-level security

Helps with info flow problems during read and write between parties of different security “levels”
SELinux implements BLP and BLP+ (BLP+ refers to BLP but do not allow read up)
MLS Policy implemented by policy constraint rules (with extra process expressions e.g. l1 and h1 to refer to low and high contexts). Also new operators like eq, dom, domby, incomparable

Covert Channels

Informal Definition: Information leakage via paths that can not be protected by MAC (i.e. not legitimate channels)

Usually caused by shared resource (CPU, network, etc.)

More technical definition: Given MAC policy M, any potential info flow from S_m to S_n is covert if it is forbidden by M
Covert channels refer to cooperating processes. If no collusion than called “side channel"
What can be done?

Detect, Estimate Bandwidth (how bad is it), Mitigation strategies.

Detection done via “Shared Resource Matrix”
Bandwidth estimation done via computation (depends on channel), but usually computing bits per time interval

Noisy channels can exist and they reduce bandwidth

Mitigation strategies

Don’t resource share
Pump abstraction for timing attacks: Insert a “MITM” device which acts as a buffer that normalizes response times to a rolling average

Real attacks

Meltdown and Spectre (technically side channel)
RamBleed

Distributed Systems Security

Basics

“Principals” make requests to request operations that exist on remote hosts
Challenges

Authentication is hard because there is no trusted path between user and trusted TCB node
Authorization between nodes implies node must speak on other’s behalf
Access control hard when resources are distributed

Handling distributed requests

Requesting principal must be at least as trusted as a principal authorized to access the resource
Communication channels must be principals themselves

Compound principals can logically exist (e.g. “Alice as Manager”, “Alice and Bob”, “Alice for Bob"
Principals make statements
Statements simply refer to types of formal logic

Getting security

Secure Communication Channels

Attacks can be passive or active
Need confidentiality, integrity, and authenticity over channel

Key Sharing

Generate K and share with A and B
A encrypts messages sent to B with K
Encrypted message includes B’s identifier for K (in plaintext)

B knows what key to use to decrypt
Share key with a key exchange protocol

Share initial key via Diffie-Hellman

Need trusted entity to assign keys to entity names: CA

CA is trusted
CA speaks for all principals

Cert revocation

CAs should be mostly offline
Certificates should be revoked —> Have an online service which tracks revoked certs and refreshes a “revocation list"
Trusting a single CA is problematic. May choose to use a hierarchy of CAs + trust chains

Secure Boot and Loading

Secure Loading

A program can be characterized by its digest (Hash)
Program P comes from trusted file system; or
P comes form an untrusted file system, but node (some principal as an OS) has a digest D for P

A loads P iff P’s computed digest matches D. Call this “attestation"

Secure Boot

If P (as above) is the OS, call this “Secure Boot"
Physical hardware is base case. Assume as part of installation M comes with keys and certificate.
Must keep keys separate from OS. Revisit SGX, etc.

Delegation

Want to differentiate a user delegating authority to “Machine as OS”, not let machine as OS become user.

Delegation: “B for A”, not “B as A” or “B speaks for A"

Requires both sides to accept delegation

Together

Encryption and secure channel protocol handle cross-node issues
Machine M, with certificate, is root of trust

Is this reasonable?

Secure boot transfers trust to OS

Challenges in practice?

Delegation during login allows a node to demonstrate to remote server that the user actually logged in

Do users have certificates?

SGX an example of this in real life

Database Security

Securing a DB requires: Authentication; Authorization; Audit, but some things are harder: Inference attacks
Want RBAC-like model for structured DBs.
Stored procedure security

Two “roles”: Definer and invoker. Definer can execute without needing separate privilege for underlying objects. Invoker must have access to objects required by procedure

DB “View” refers to a subset of the actual DB such that the resulting data matches a specific user’s security level
Inference Attacks

Functional Dependency attacks: Get (Name, Rank), Get (Rank, Salary). Combine to disclosure salary for name.
Statistical queries: Use statistics averages to guess sensitive data with high precision
Defenses:

Don’t allow queries that return sufficiently small or large results. However, can be broken using Tracker attack

C1 = Female students
C2 = Out of state students
T(Tracker) = C1 AND ~C2

q(C) = q(C1) - q(T)

Better solution: De-identification and Differential Privacy

K-Anonymity

DB transformed so at least k different rows with same “trace” are produced
Utility of DB drops with increasing K
Linking attack s and l-diversity are still a problem

Differential Privacy

Curator will add noise to response R to return R'
This needs to be done carefully so noise cannot be easily cancelled out with multiple queries
Guassian or Laplace mechanism - noise derived from these distributions
Local differential privacy (LDP)

Users locally perturb their data and share it
No need for trusted curator

What about Multi-Level Databases. e.g. Can we add BLP to databases?

SeaView once such instance of a MLD with BLP support
Access class is assigned at an element in row
Tuple access class is LUB of access classes of elements in tuple (row)
Relation/table access class is GLB of any element in a type in table
Database access class is GLB of any table access class.
In order for data to be accessible, tuple key access class is the least privileged class in a tuple
User’s see elements in a “read down” fashion. If sensitive data is too high, cause it to become NULL
Poly-instantiation

Visible: A lower access class value is visible to higher access class user but is not overwritten
Invisible: A lower access class level user does not see a more sensitive value