Secure Operating SystemsLesson 10: SCOMP

Where are we? Multics is busy being explored, which is kind

of cool… But Multics wasn’t the end of custom built

operating systems designed with security in mind: it’s natural successor was SCOMP

SCOMP: Verification Unlike Multics, the designers of SCOMP

wanted verifiable security, and so the goal was chase the fledgling TCSEC A1 evaluation

We don’t see formal methods a lot day to day, but the value is we (theoretically) know the product conforms to its specfications However, we do NOT know if the specifications

are good…

A Quick Aside: TCSEC Trusted Computer System Evaluation Criteria AKA “Orange book” from the “Rainbow

series” TCSEC still matters, though it was replaced

by what is known as the “common criteria” in 2005

Defined multiple levels of security for a system (note that word)

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.

Design Choices Some of the design choices in SCOMP were,

I think, interesting The designers threw some compatibility away

in the name of security, which I think was clever – as such, SCOMP was not Unix

One particular problem they tried to address was interfacing groups with different security levels – a tough problem

Reference Monitor Remember, the requirements for a reference

monitor: Complete mediation Isolation Verification

The “Security kernel” concept

Segment Access Control Simple ACL

Segments: read, write, execute Directories: status, modify, append

However. The SDW also includes rings and brackets – this can be a little tricky

To grant access, the ACL and Access brackets must both allow…

Mediation Memory protection looked like this in

SCOMP (source: “SCOMP: A Solution to the Multilevel Security Problem”):

Isolation Just like Multics, though there were 4 rings

(sound familiar?) Ring brackets were used (just like Multics) to

provide control over operations

SCOMP Hardware Implementation SCOMP used a security protection module

which interfaced with the Virtual Memory Interface Unit

The mechanism of the SPM is critical to SCOMP

Mediation is trap based

Clever: IO SCOMP used descriptors for IO, similar to

memory descriptors Because mediation happens in hardware, the

drivers themselves do not need to be in Ring 0, decreasing the size (attack surface) of the security kernel Remember, this is all A1 stuff… what happens

when we change it?

DMA SCOMP did allow DMA for speed The initial transfer is mediated by the SPM There is a similar approach taken to virtual

addresses, which is a little safer (why?)

Argument Addressing Mode Remember that whole confused deputy thing? SCOMP had an “argument addressing mode”

which allowed the system to attempt to access parameters with the level of protection of the caller in hardware (avoiding software checks – clever stuff)

SCOMP was small Security Kernel: about 10k lines Trusted software: about 11k lines SCOMP also has a “secure attention” key,

which allowed a user to be sure that they were accessing the OS not something “in the middle”

SCOMP Kernel Interface Package SKIP:

Provide a hierarchical multilevel file system Provide the ability to create child processes Allow for process synchronization Provide an efficient interface Provide a low-level general purpose interface

Not an OS, but an interface to a secure environment

Things to Do Read: “SCOMP: A Solution to the Multilevel

Security Problem”

Questions & Comments What do you want to know?