[cap-talk] Reducing Ambient user authority in a Type Safe /Memory Safe OS.

[Rob Meijer]

On Tue, December 15, 2009 14:02, Ben Kloosterman wrote:
> Thanks Toby , I will have a closer look at Plash tomorrow it looks
> interesting from the point of view of binary dependencies.
>
> Note the escalations are a bit different from  Windows UAC and sudo due to
> the fact that the granularity is application (per user) instead of user
> and
> there is no su account. Because by default an application has no authority
> everything needs to be added.
>
> The idea with the escalations is that there is little Ambient authority
> from
> the user and on a totally secure system   you can with a policy setting
> disable it. However I would argue that without such an escalation most
> initial install settings would need to be looser eg instead of saying only
> word has r/w access to  .doc files in the home directory and only excel
> .xls
> you get the situation that all applications have full access to the users
> home directory. With escalation you can use very tight settings and then
> escalate them as needed, after a short time all the settings would be in
> place.

In MinorFs ( minorfs.polacanthus.net ) I use a more radical approach.
The user its home and the temp directory facility should simply be
considered to be global mutable state that should be avoided. AppArmor van
be used to give only read permissions to this global state, and MinorFs
provides a private replacement for both provisions.
Each process gets its own private temp directory that gets removed ones
the process dies. Each pseudo persistent process (A combination of uid,
invocation chain, slot and optionally command-line arguments) gets its own
private home directory.

I can imagine that the MinorFs approach to 'no implicitly shared mutable
state' may be a bit to purist for your liking.
For your system you may thus consider to go for the somewhat lower
granularity of the uid-exe combination. This would than be aproximately
equivalent to static variables in programing languages.
You may however wish to consider that the invocation chain and sometimes
the command line arguments are indeed relevant. I would thus suggest going
for the same combination as MinorFs with the exception of the slot.
This greatly reduces the problems with implicitly shared mutable state
that we should try to avoid.

For MinorFs a directory is a decomposable unidirectional tree-graph.
Each node within a directory tree has its own sparse-cap strong path that
can be delegated as a sub tree, where delegation of a sub tree does not
give any capabilities to or trough parent nodes. Currently its just
decomposition and no attenuation (all caps are rw). I still need to find
some time (or find someone who has some time) to write up a caretaker
based file-system to accommodate for attenuation and revocation. Adding a
file-system that implements COW as a composition pattern is also a pretty
interesting concept that I hope to allocate some time to in the future.
The concept would be that you could compose a COW directory using a read
only path (either strong or weak) and a rw strong path.

Ben, I think that MinorFs minus the slots and plus a yet to implement
caretaker based filesystem for attenuation and revocation would probably
fill your needs without having to resort to the backwards compatibility
nightmares that come with the globally mutable versions of $HOME and $TMP.



Rob