[cap-talk] Why arn't safer OS being used. [ was Confessions of a C programmer]

[Toby Murray]

2009/9/28 Mark Miller <erights at gmail.com>:
> I protest. I very rarely do this, but I feel this is just too
> off-topic and inappropriate for cap-talk. Please let us stop
> discussing corporate culture, brain rotting, etc, unless it has some
> direct relevance to capabilities. Even then, we should tone down the
> ad hominem nature of this discussion.
>

I concur.

I think a more constructive debate would be this:

"Given an object-capability microkernel like seL4, how would you build
a desktop environment on top that was as backwards-compatible as
possible?"

I think this is inherently do-able. I don't think backwards
compatibility needs to be sacrificed to do it. Plash has many ideas
that can be borrowed, like:

- virtualising the standard filesystem interface to allow each
application to run in its own namespace whereby it can be given e.g.
copy-on-write access to various files etc.
- A version-controlled filesystem with simple rollback could also be
useful. (think e.g. how Wikipedia maintains consistency in the face of
malice as suggested by Zittrain)
- Installing entire applications with all of their dependencies in
their own namespace (as e.g. Plash does) gets you most of the way
there.
- Standard config dirs like /etc/ or /home/user/.gconf.d/ etc. can be
virtualised as well and reside (and even be distributed between) the
private namespaces of each application.
- Static permissions like "webcam access", "microphone access" etc.
could be inferred from an application's position in the "Start Menu"
(as suggested by Ka-Ping Yee once upon a time),
- a "File Open" powerbox can be used for dynamic grants as e.g.
Polaris and Plash do.
- The desktop shell could store things like the information and
passwords etc. for your mail server. This could be shared only with
"Email Applications", as inferred by the shell based on an
application's name or again position in Start Menu.
- The same applies to web browsers and other standard pieces of software.


Backwards compatibility should be sacrificed only if in the process
you implement something which is prima facie far more secure and
usable than the status quo.

Cheers

Toby