Transcript Win32 Programming

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



B: Mandatory Protection


C1 – discretionary security protection
C2 – Controlled access 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?