1. Secure Operating Systems Lesson 10: SCOMP

2. 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

3. 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…

4. 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)

5. 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.

6. 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

7. Reference Monitor  Remember, the requirements for a reference monitor: Complete mediation Isolation Verification  The “Security kernel” concept

8. 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…

9. Mediation  Memory protection looked like this in SCOMP (source: “SCOMP: A Solution to the Multilevel Security Problem”):

10. Isolation  Just like Multics, though there were 4 rings (sound familiar?)  Ring brackets were used (just like Multics) to provide control over operations

11. 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

12. 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?

13. 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?)

14. 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)

15. 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”

16. 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

17. Things to Do  Read: “SCOMP: A Solution to the Multilevel Security Problem”

18. Questions & Comments  What do you want to know?