Today's plan

• amoeba, continued
• multics overview
• multics security review
• operating system security 30 years later

Amoeba Concepts

• objects are abstract data types
• for example, a directory object supports operations such as create a name/value pair, and look up a value given a name
• each object is managed by a server process (a server may manage multiple objects) to which messages are sent via RPC
• each object has a capability, which is assigned when the object is created -- a kind of digital signature
• the capability is included with every request to a server

Amoeba application services

• the Bullet file server only stores contents, not names (but can be used, e.g. to store directories, whose contents are names)
• no blocks -- all files stored contiguously on disk, and loaded or written (or sent across the network) as a unit
• files are identified by a capability
• the directory server stores pairs of (name, capability), and can therefore be used to index things other than data on disk
• each directory entry may actually have multiple capabilities, which allows for replicated services and for selecting the "nearest", "best", or "available" object
• Orca programming language makes parallel programming more explicit
• Posix compatibility library (Ajax)
• TCP/IP server provides standard networking

Process Migration

• e.g. see http://citeseer.ist.psu.edu/steketee94implementation.html
• for a short summary of process migration issues, see http://www.cs.panam.edu/~meng/Course/CS6334/Note/master/node24.html
• Amoeba's process migration was added after the basic operating system development
• processes may only migrate among machines with the same architecture (homogeneous process migration)
• the process migration server will only migrate processes with a valid process migration capability
• migration servers on the source and destination work with process servers on the source and destination to get the process set up and running again
• messages to a process that is migrating are failed in such a way that the sending FLIP will try again after a short delay
• messages to a process that has migrated receive a "moved" message, which causes the sending FLIP to search for the process's new location
• an execution token is passed by the sender to the destination once the transfer is complete, so that only one copy of the process may be running at any given time

Multics overview

• an early time-sharing system (inspired Unix)
• designed for interactive use
• much of it programmed in a high-level language (PL/1)
• potentially multiprocessor

Multics security

• didn't want to repeat the insecurities of previous time-sharing systems
• hardware segmentation (with paging), with each segment having access protection bits
• segments are persistent and are stored in directories which have Access Control Lists (ACLs)
• hardware rings -- 8 concentric rings of protection, implemented as a separate descriptor table for each ring
• rings were designed to be implemented in hardware, actually implemented by having "master mode" be ring 0 and providing facilities to cross from one ring to another. When a program tries to add a segment to its space, ring 0 checks the ACL.
• process table entries contain a user ID and are only accessible from ring 0
• passwords are stored encrypted, but the passwords file is also inaccessible to users
• users are told when they last tried to log in
• all system code is reloaded from tape when rebooting

Multics attack

• classic paper, e.g. at http://csrc.nist.gov/publications/history/karg74.pdf by Karger and Schell
• conclusion: not secure enough to have untrusted users share the computer with classified documents
• attacks designed to break hardware, software, and procedures, to the point of being able to access or modify "protected" data
• attackers had access to software and to hardware design (no "security by obscurity")
• attacks designed on a computer on an Air Force Base, then reproduced on a similar computer at MIT
• attacks should be undetectable, e.g. not cause anomalous crashes
• random tests of illegal operations or parameters to try and find unexpected behavior
• random tests uncovered a hardware bug that allowed some accesses to go unchecked (the bug had been introduced after the original design by an "upgrade")
• gate 0 code uses a routine to determine if argument lists are valid, but an autoincrement feature could lead the check to succeed but the actually accessed word to not be permitted
• a procedure (the "signaller", to deliver signals to user processes) was for efficiency placed in user space ("user ring") but ran in master mode, allowing a careful user to transfer to arbitrary code while still in master mode
• a change in usage of the stack segment register allowed user programs to store the registers in an arbitrary segment on a context switch, e.g. allowing the installation of a trap door into user code
• procedural vulnerabilities included physical access, the ability to use the software attacks to masquerade as a different user or change arbitrary memory or files, modifying the software at the development facility or enroute
• trap doors include modifying the TTY driver to recognize a special string, and modifying the compiler to recognize itself (and produce a trapdoor-generating compiler) and a given piece of code
• overall result: securing a system takes much more work than breaking in to a system!
• suggestion: a small (understandable) security kernel might do the trick

Multics 30 years later

• new paper, e.g. at http://www.acsac.org/2002/papers/classic-multics.pdf, also by Karger and Schell
• Multics had security as its goal from the start, other systems don't (and therefore are weaker)
• modifying other systems to be more secure may interfere with "normal" usage, so the code base forks
• Multics did not suffer from buffer overflows, since PL/1 is safer than C and the segments prevented memory misuse
• Multics stacks grow upwards, so an overflow does not overwrite the return address
• Multics is simpler than most current systems, e.g. Multics ring 0 is much smaller than the SELinux security module
• intrusion detection often does not deal with the possibility of professional attackers who refine the attack on their system before attacking the target
• the GEMSOS OS certified to "Class A1" security standards, so the technology exists
• why aren't we doing better?
• chicken and egg problem: makers don't think customers want it, customers don't know makers can do it