Most of this things in this talk are:

• Pure Speculation


• Designed, but not implemented


• Partially Implemented


• Implemented, but full of bugs

How is this different to any other system?

• Better Security
No setuid hacks


• Easier programming model
fork(), select(), signal(), mmap()


• Modular system structure
User-loaded/untrusted 'file systems'


• Fine-grained access control
No UMGs or `chmod o+r'


• Confinement and accounting of untrusted/bloatware applications
Netscape, [x]emacs, anything with GNU in it


• Emulate legacy operating systems (UNIX)
So we can run Netscape, [x]emacs, anything with GNU in it

• Threads
Unit of execution


• Semaphores
Synchronisation


• Persistence and Distribution
Just because they are cool


• PDX
Rights modification and secure invocation


• Single address space
Shared namespace

• Capabilities
Access control


• Bank Accounts
Resource management

• Accounting for everything a thread wants to access is a pain
May not be known until run-time


• Capabilities could come from yourself, other users, groups, everyone
Mungi doesn't let an APD have that many caps!


• Pre-loading capabilities causes performance problems
Mungi does O(n²) validations


• Capabilities can be added, removed and changed at run-time.
We don't want to restart gv to refresh the display


• Solution: Do it lazily!
It's the Mungi way


• User-Interface advantages?

• Implement a sane lpr


• Much better support for least-privilege
Hacking lpr doesn't give you much

• Users don't need names in capability systems


• Applications can shed capabilities easily
...or not demand load them


• Create temporary 'sub-users'


• Effective confinement!

• Resource Confinement/Limits
Create a bank account with limited funds


• Cheap Caches
Delete items just before you get charged for them


• Clean Up
Run leaky apps in their own bank account


• Per-'process' Accounting
Just plain cool


• Fine-grained charging
Databases can charge by the row

• Breaking UNIX security is easy
find / -perm +4000


• Mungi is more secure... right?

• Don't use PDX?


• Don't share objects?


• Serialise pointers?


• Work in Progress...

DO

• Create threads to call untrusted PDX entry points

DON'T

• Create 'Server' threads


• Let others create threads in your APDs


• Give others capabilities to your stack or heap

DO

• Use semaphores for thread safety

DON'T

• Share semaphores outside your APD


• Use semaphores to create blocked server threads

DO

• Take advantage of persistence


• Remember that things could run on different nodes

DON'T

• Use strtok() on persistent data


• Serialise data into XML

DO

• Use PDX as much as possible


• Use MCS when using PDX


• Make code as event-driven as possible


• Pass whole capabilities, not just pointers

DON'T

• Trust pointers and caps passed to PDX services


• Use PDX to copy large chunks of data around


• Put MCS in the kernel

DO

• Give every 'thing' a name in the SAS


• Use capabilities for protection where possible

DON'T

• Create other address spaces


• Build systems relying on cache timeouts


• Try to use AS sparsity for protection

• User-Level
Safer


• Event Driven
Fewer threads hanging around


• Not connection oriented


• No need for screen


• Persistent login sessions are easy


• Session semantics?

• lpr


• Plan-9 Style Naming


• Unbounded Heap


• Windowing System

• UNIX lpr is insecure


• setuid is a broken idea


• Mungi is naturally better

• Per-'process' namespaces
$PATH is just plain wrong


• Encapsulate names into a directory service


• Mutual distrust


• Built with the Mungi Component System (MCS)

• malloc() is persistent


• How long is a piece of string?


• We can't safely share pointers across APDs


• open/close/read/write involve copies
Also forbids the use of storing pointers


• ObjCreate/ObjResize creates another address space
Storing offsets is serialisation


• We need a meta-data service!
It also conveniently implements UNIX files

• Transactions
Session semantics


• Shrinking heaps


• Sparse heaps
Another address space


• Solve it with fault handlers?

• Apps will be running on different nodes
Minimise sharing (including threads!)


• Input devices could be on different nodes


• A recursive windowing system like Plan-9 would be cool


• Someone needs to design and build this!

• UNIX has many apps we want


• I'm not going to re-write and maintain them


• There's nothing fundamentally wrong with the UNIX model

• MASOS by definition
fork()


• Files and Pipes


• Signals


• Job Control

• Job Control


• setuid


• root


• ioctl


• IPC Primitives


• 'All or Nothing' protection

• Use an unbounded heap


• What about mmap()?


• Exact UNIX semantics?

Advantages

• Fits the device model
cat > /dev/hda


• No useless server threads

Problems

• Clean-up
Session semantics (again)


• Requires thread synchronisation


• Exact UNIX semantics?

• Most programs fork() to exec()


• Lazy programmers modify the stack and heap


• We can't just let the caller's data get trashed... can we?
ucLinux hack

• Caller backs up stack and heap using COW


• Caller creates callee thread and blocks


• Callee runs until it calls exec()


• Callee unblocks caller before jumping


• Caller restores original stack and heap

• It's a hack


• Buggy code can still access the caller PD


• No caller/callee communication between fork() and exec()


• Callee is under control of the caller
No kernel guarantees. setuid problems?

• Some programs want fork() semantics
apache, squid, shells


• Often for the wrong reasons
Threads, select()

• Caller duplicates stack and heap


• Caller creates callee with modified stack and data pointers