Secure Operating SystemsLesson 0x11h: Systems Assurance

Where are we? Really, we’re now just looking at the loose

ends of OS Security But there’s one question we don’t have an

answer to: how do we KNOW an OS has particular properties?

Verification The aim is to verify that a system enforces a

desired set of security goals Example: are two sets of users separated?

Are the mechanisms (e.g. reference monitor) and policies (e.g. MLS) appropriate to enforce the goal?

Are these ideas implemented correctly? Assurance concerns itself with what and how

Building secure things is HARD Three Steps:

Define the security goals (clearly!) Design for verification (ideally, using formal

methods) Build so that the system can be mapped back to

the verified design

Assurance Standards Historically, Orange Book (part of TCSEC) Now, The Common Criteria We will take a look at both approaches

Orange Book A-D D: Minimal Protection C: Discretionary Protection

C1 – discretionary security protection C2 – Controlled access protection

B: Mandatory Protection Labeled Security Protection, Structured Protection,

Security Domains (B1, B2, B3) A: Verified Protection

A1 – Verified design Beyond A1 – speaks to physical root of trust etc.

D: Minimal Protection Government-speak for “evaluated but failed

to meet the requirements of anything higher” (!)

Rule of thumb: D is probably not very helpful (what does it actually tell you?)

C1: Discretionary Sec. Protection DAC: Permissions of named users to named

objects System actions are performed by hardware-

protected domains No obvious ways to bypass controls Basic documentation required

C2: Controlled Access Protection Rights must be specifiable at the level of the

single user Authentication based on a secret that is

protected from others Audit of particular events in a protected log Object reuse checked – new objects do not

“leak” data from previous uses C2 is our “day to day” security level

B1: Labeled Security Protection C2 plus MAC Named objects must be associated with a

sensitivity label, corresponding to an MLS policy

Security mechanisms must work as claimed in the documentation (how to verify?)

B1 requires proof of detailed testing – few OS are in this level

B2: Structured Protection Adds protection/enforcement to all objects Requires covert channel protection Authentication requires a “trusted path” The Trusted Computing Base must be

“relatively resistant to penetration”

B3: Security Domains Extends the TCB to cover the “reference

monitor” concept TCB is “highly resistant to penetration”

A1: Verified Design A formal model of the security policy, plus a mathematical

proof that the model is consistent with the policy A Formal Top Level Specification (FTLS) of the functions

the TCB performs The FTLS of the TCB must be shown to be consistent

with the formal model of the policy The TCB implementation must be consistent with the

FTLS Formal analysis must be used to identify and analyze

covert channels

Beyond A1 A1 allows informal verification if no formal

tool exists This class was left open to allow for a system

that can be verified more precisely

Formal Methods It’s possible to apply formal methods to computing

problems Essentially, prove mathematically that a system functions a

certain way The needs for formal methods are huge: most modern

systems are really computers with moving parts To get 10-7 failure rates, we cannot rely on visual

analysis Exhaustive testing is impossible due to state space explosion

Testing? Debugging requires either examining a crash,

or choosing the right test cases Good coverage is impossible for real systems Formal methods cover all behaviors, and is

certain to find the bugs… provided the model, environment and properties are correct However, all problems are NP-hard, and most are

superexponential or even undecidable

Common CriteriaLevel Requirements

EAL1 Functionally tested

EAL2 (C1) Structurally tested

EAL3 (C2/BA) Methodically tested and checked

EAL4 (C2/B1) Methodically designed, tested and reviewed

EAL5 (B2) Semiformally designed and tested

EAL6 (B3) Semiformally verified design and tested

EAL7 (A1) Formally verified design and tested

Aside: ITSEC and AV Anti-malware provides some really

interesting challenges to all this… let’s discuss

Questions & Comments What do you want to know?