[cap-talk] MinorFS presentation.

[Rob Meijer]

On Mon, June 1, 2009 21:01, Karp, Alan H wrote:
> Rob Meijer wrote:
>>
>> I borrowed the solitaire example from Alan Karp, hope that's alright.
>>
> I don't mind since Stiegler didn't mind when I stole it from him.

Great, tnx.

> One minor comment on your slides: The URLS on slide 35 are very hard to
> read.  You should change them to a light color.

Check,

I've put an updated version on http://polacanthus.net/MinorFS.pdf ,
and Bob is in it again now (tnx Zookoo) :-)

> Some thoughts on the talk.
>
> Slide 5: I don't see how the solitaire example is related to mutable
> state.  In particular, you can troll for secrets without mutating
> anything.

I get to that in slide 8, showing that OO-Writer and Sokoban (Could be
Solitaire and MS-Word in the MS world) sharing mutable state (that is
the $HOME and/or $TEMP) could be the source of potential problems.
If I trust my data to OO_Writer and OO-Writer can only use implicitly
shared mutable state based persistent storage to store my data, than I
implicitly am trusting all other programs, including sokoban or solitaire
with my data.

> Slide 11: I'm not sure that global mutable state violates POLA as much as
> it makes it virtually impossible to enforce.

I may have beem to strong a statement, I've toned it down a bit to
"High potential for violating the principle of least authority"

> Slide 28: How do you ensure that the right process claims a PPPID?

MinorFS calculates a PPPID from the information listed on slide 28.
This means the next incarnation of the pseudo persistent process is an
instance of the same program started under the same uid using the same
invocation chain (and for some programs commandline and enviroment are
relevant). If a process uses the $HOME and $TEMP provided by MinorViewFS
to store its persistent state, it is access to this persistent state that
makes the process the right process. The best example of this is that of
a persistent e program as described in slide 31.


> Slide 32: I assume the words behind the slide explain where the line
> counts come from.
>

The left side shows a situation where a user has a set of 20 programs he
uses, including programs he uses on important data, but also including
programs he uses for other often unrelated tasks. Than we look at a
particular piece of data that the user wants to protect. A sensitive
document containing data that should neither be disclosed nor lost.
I than go on that there are two programs that legitimately could need
access to this data, the editor and the encryption software.

So using MinorFS we could go from 20 trusted programs to 2 trusted programs.
Than saying that each of the 20 programs would be about 50.000 lines of
code, there would still be about 100.000 lines of trusted code on our
system of the original 1.000.000 lines.

Using the multy-storey (AppArmor/MinorFs/E with persistence) approach and
using a persistent capability secure language, the two programs could
likely be divided into multiple modules where only 1.000 of the 50.000
lines of code would need to be 'powerful' lines of code.

The result being that of the original 1.000.000 lines of trusted code, the
multy-storey approach would leave us with only 2.000 lines of trusted
code.


Rob.