Secure Operating Systems

Secure Operating Systems Lesson 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?

Secure Operating Systems