æSec™

Towards Formal Evaluation of a High-Assurance Guard

Mark R. Heckman <mark.heckman@aesec.com> Roger R. Schell <roger.schell@aesec.com> Edwards E. Reed <ed.reed@aesec.com>

0

2012 Layered Assurance Workshop, Dec 3 – 4, Orlando, Florida

æSec™ Transfer Guards

•  Type of Cross Domain Solution •  Permits the movement of data between domains •  Blocks the data that shouldn’t be released

–  Key word scans, to block release of high data to low –  Creation of sanitized data out of sensitive data –  Antivirus scan for transfers from low integrity to high

1

High Domain

Downgrade

Low Domain

æSec™ Current Transfer Guards

•  Built on low-assurance base operating system –  E.g., EAL 4+ (SELinux, Trusted Solaris)

•  Can’t limit range of trust –  Need separate system for each guard/domain –  Redundant systems: Guard server “farms”

•  Susceptible to software supply-chain subversion –  Trusted distribution? System integrity? Secure

recovery?

•  Lack sound system composition method •  Require repetitive, total system recertification

–  Due to changes to policy, HW/SW, configuration

2

æSec™ High-assurance Transfer Guard

•  Guard as application built on TCSEC Class A1 TCB •  A1 TCB base solves problems of

–  Susceptibility to supply-chain subversion –  Resource redundancy due to range of trust

•  Need sound composition method –  Permits “divide and conquer” formal evaluation –  Permits incremental (re)evaluation

3

æSec™

TCB

Guard 1 Guard 2

Downgrader 1

Downgrader 2

High Producer 1

Low Consumer 1

High Producer 2

Low Consumer 2

Abstract Transfer Guard

4

•  Components: − High producer of information − Downgrader − Low consumer of information

•  TCB permits multiple downgrade ranges

æSec™

TCB

…

Abstract Downgrader

5

Downgrader  Stage  1

Downgrader  Stage  n

Downgrader  Stage  2

•  Possibly multiple, distinct policies

•  Pipeline or other arrangement

æSec™ Aesec Virtual Guard (AVG)

•  Implementation of Abstract Transfer Guard •  Designed for high-assurance base – GEMSOS

–  Gemini MLS Operating System implements • Bell-LaPadula access control • Biba mandatory integrity

–  Evaluated at TCSEC Class A1

•  AVG takes advantage of GEMSOS mechanisms –  Process isolation –  Multi-level subjects with restricted range –  Assured pipelines using GEMSOS MAC labels

6

æSec™

GEMSOS

Low Process Family

Read : L:ic1,ic2,ic3 Write :L:ic1,ic2,ic3

Release Process Read : H:ic1,ic2 Write : L:ic1,ic2

Network Clients

Low Assured Pipeline

Read : L:ic1,ic2 Write : L:ic1,ic2,ic3

High Process Family

Read : H:ic1 Write : H:ic1

Network Clients

High Assured Pipeline

Read : H:ic1 Write : H:ic1,ic2

Storage Object Name, Label

Process Family

Read Label Write Label

Legend:  

Network Clients

Label: H:ic1 Label: L: ic1,ic2,ic3

Trusted Guard Downgrade

Function

High Message Buffer, Label:

H:ic1,ic2

Input Message Handler

-------------------- NFS Daemon

Input Queue Manager

High Message Queue

Label: H:ic1

Low Message Buffer, Label:

L:ic1,ic2

Output Message Handler

------------------- NFS Daemon

Output Queue Manager

Low Message Queue

Label: L:ic1,ic2,ic3

Labels use Secrecy Levels (H, L) and Integrity Categories (ic1, ic2, ic3)

AVG Architecture

Process Name

æSec™ Assured Pipelines

•  Sequences communication between processes •  Like a train, can’t bypass a station •  Controls flow of data to/from downgrader •  Orders downgrader stages •  Implemented in AVG using Integrity categories

8

æSec™ Assured Pipelines in AVG

•  Biba Integrity: –  The Simple Integrity Axiom: no read from a lower

integrity level (no read down) –  The * (star) Integrity Axiom: no write to a higher level

of integrity (no write up)

9

Low Process Family

Read : L:ic1,ic2,ic3 Write :L:ic1,ic2,ic3

Release Process Read : H:ic1,ic2 Write : L:ic1,ic2

Low Assured Pipeline

Read : L:ic1,ic2 Write : L:ic1,ic2,ic3

High Process Family

Read : H:ic1 Write : H:ic1

High Assured Pipeline

Read : H:ic1 Write : H:ic1,ic2

Input Queue Manager

High Message Queue

Label: H:ic1

Output Queue Manager

Low Message Queue

Label: L:ic1,ic2,ic3 High

Message Buffer, Label:

H:ic1,ic2

Low Message Buffer, Label:

L:ic1,ic2

Output Message Handler

------------------- NFS Daemon

Input Message Handler

-------------------- NFS Daemon ic1 <

ic1,ic2

ic1,ic2 < ic1,ic2,ic3

æSec™ Adding Downgrader Stages

•  Use additional integrity categories •  One additional category per stage •  Sequence of non-bypassable stages •  Modular, but confined, security policies

10

Stage 0

Read : ic1 Write : ic1

Pipeline 1

Read : ic1 Write : ic1,ic2

Pipeline N

Read : ic1,…,icN Write : ic1,…,icN+1

Stage N

Read : ic1,…,icN+1 Write : ic1,…,icN+1

…

æSec™ Guard Identifiers

•  Start with basic process separation •  Add unique integrity category for each guard

–  “Guard identifier”

•  “ic1” is guard identifier in figure –  Assigned to every process and storage object

11

High Message Buffer, Label:

H:ic1,ic2

Input Queue Manager Read : H:ic1 Write :

H:ic1,ic2

High Message Queue

Label: H:ic1

Low Message Buffer, Label:

L:ic1,ic2

Output Queue Manager Read :

L:ic1,ic2 Write :

L:ic1,ic2,ic3

Low Message Queue

Label: L:ic1,ic2,ic3

æSec™ Multiple Virtual Guards

•  Each guard has unique guard identifier •  Biba Integrity policy protects guard

–  Different integrity categories are non-comparable –  No flow between guards on same server

•  Can have different secrecy levels and ranges

12

Guard A

Guard B

Guard C …

GEMSOS

æSec™ Performance

•  Prototype runs on single 550 MHz IA32 CPU –  Did not use GEMSOS multiprocessing feature

•  Single “dirty word” search downgrader •  Processing measured within server, independent

of transfers •  2500 msgs/sec

–  4KB message size

•  Primarily CPU bound

13

æSec™

TCB

Guard 1 Guard 2

Downgrader 1

Downgrader 2

High Producer 1

Low Consumer 1

High Producer 2

Low Consumer 2

Abstract Transfer Guard Proofs

14

•  Can Producer/downgrader/consumer be composed into a guard? •  Guards isolated? •  Downgrader evaluable separately from TCB?

æSec™

TCB

…

Abstract Downgrader Proofs

15

Downgrader  Stage  1

Downgrader  Stage  n

Downgrader  Stage  2

•  Does each stage correctly enforce its policy?

•  Stages composable? •  Ordering and

isolation properties

æSec™ Composition Problem

•  Interconnected components •  Each has known security properties •  What are security properties of system? •  Want to use arguments about components to

make arguments for entire system –  Without having to reanalyze

16

æSec™ Unconstrained vs. Constrained

•  Constrained composition: –  Specific properties –  Specific interconnections –  Practical solutions exist –  E.g., TCB Partitions and TCB Subsets

•  Unconstrained composition: –  Arbitrary properties –  Arbitrary interconnections –  No general solution known (or possible?)

17

æSec™ Classifying Proof Obligations

•  Infrastructure –  Guards isolated? –  Ordering and isolation properties of downgrader stages –  Can Producer/downgrader/consumer be composed into

a guard? –  Downgrader evaluable separately from TCB?

•  Non-infrastructure –  Does each stage correctly enforce downgrade policy? –  Can stages be composed into the downgrader?

18

Unconstrained composition

Constrained composition

æSec™ Guard Isolation/Stage Ordering

•  GEMSOS-enforced process isolation •  GEMSOS mandatory integrity used for … •  Guard isolation:

–  Guard identifier integrity categories

•  Downgrader stage isolation and ordering –  Assured pipelines –  Implemented using integrity categories

19

æSec™ Producer/Downgrader/Consumer

•  Trusted Network Interpretation of TCSEC –  Virtual machine is example of “network component”

•  Downgraders are virtual machines –  Due to guard identifiers

•  Downgrader on TCB is NTCB partition •  Producer and consumer are also NTCB partitions •  Use TCB Partitions technique (TNI) to compose

20

æSec™ Downgrader Separate from TCB

•  Two policy-enforcing entities •  TCB policy

–  Includes notion of multilevel subject –  Limits range of multilevel subject –  Isolates trusted subject

•  Downgrader policy –  Defines what trusted subjects do within range

21

æSec™

TCB Downgrader

System Policy Specification Sketch

•  Mandatory access control (MAC) •  Downgrader isolated by guard identifier (GI) •  Downgrader protected domain policy D

22

High

Low

No read up; no write down (MAC)

High + GI

Low + GI

Write down (D)

æSec™ TCB Subsets (from TDI)

•  Less-primitive subset (Downgrader) •  More primitive subset (TCB)

–  Strict MAC policy –  Permits trusted subjects in less-primitive subset

domain

•  Tamperproof and mandatory system config. –  Guard identifier creates isolated protection domain –  Downgrader range

•  Security properties of TCB unaffected by changes to the downgrader policy

•  Hence, can use TCB Subsets technique

23

æSec™ Balanced Assurance

•  Less-primitive TCB subsets –  Constrained by underlying, general-purpose TCB –  Have correspondingly lower risk –  Do not require all Class A1 assurance techniques

•  Downgrader is such a less-primitive TCB subset •  But, downgrader is trusted •  Does it have lower risk? •  Yes, because does only one thing – downgrading •  TCB-enforced isolation prevents anything else

24

æSec™ Downgrader Arguments

•  Program verification needed •  But what is policy model? •  Multiple policies è Unconstrained composition

•  AVG provides necessary support •  Verified programs requires code integrity

–  A1 TCB specifically addresses subversion

•  Composition of stages requires assured ordering –  Assured pipelines and guard identifier

25

æSec™ Conclusions

•  Can evaluate downgrader separately from TCB –  Permits “divide and conquer” formal evaluation –  Permits incremental (re)evaluation

•  Supports multiple downgraders on same system –  Due to high-assurance base

•  Separates constrained from unconstrained composition –  Increase confidence in overall evaluation correctness

26

æSec™

Towards Formal Evaluation of a High-Assurance Guard

Mark R. Heckman <mark.heckman@aesec.com> Roger R. Schell <roger.schell@aesec.com> Edwards E. Reed <ed.reed@aesec.com>

27

2012 Layered Assurance Workshop, Dec 3 – 4, Orlando, Florida

Questions?