Re: E + MinorFs + AppArmor: adding Tahoe to the stack ?

On Tue, January 26, 2010 22:09, David Wagner wrote:
> Rob Meijer wrote:
>>Unfortunately it seems almost impossible to make MinorFs/AppArmor
>>enthusiasts to even try the (admittedly esoteric) e language, or to get
>>any response at all from the e language community on the usage of
>>MinorFs/AppArmor.
>
> I can't speak for others, but the reason I have not responded is I
> have not understood what is the killer benefit MinorFS provides or
> what the big win would be for those who buy into it.

AppArmor allows to keep processes from getting at each others internals,
for example using /proc/$PID, and for taking away write access
for the regular $HOME and $TEMP and other implicitly shared mutable
sections of the shared filesystem namespace. This leaves processes without
any write access within the shared namespace filesystem hierarchy, and
without access to each others internals that might provide access to
private
storage area's.

On top of this foundation MinorFs provides that it :
* Takes away the need for using system or user global $HOME and $TEMP
  provisions by providing for a 'private' alternative.
* Elevates the granularity of persistent disk storage facilities from the
  'user' granularity to the 'pseudo persistent process' granularity.
* Allows for decomposition and delegation of parts of this private storage
  to other processes.

The $TEMP is provided as a private facility to regular processes, so this
works great with any language. The $HOME provision is provided however to
pseudo persistent processes, where the program is responsible for
serializing itself to the private $HOME.

The E language IMO is a great fit for usage of CarvFs for two reasons:
* It has a provision for persistent VATs, making it a perfect fit for the
  $HOME facility. It can safely allow E applications to serialize to their
  own persistent process state to its own private $HOME, extending the
  inter process security to persistent VATs.
* It (being a ocap language with support for percistence) elevates the
  granularity  of persistent disk storage facilities from the 'pseudo
  persistent process' granularity to the 'object' granularity.

To sum it up what I would consider the 'killer benefit' would be for
E users: 'It has the potential to close the "attack from below" hole for
persistent E applications.'

>>1)   Do you feel it is realistic to bridge the apparent gap between
>>     MinorFs/AppArmor enthusiasts and e-language enthusiasts? And if so
>>     what  would be needed to do this?
>
> I don't know enough to say, but as a general principle, it is hard
> enough as it is to get people to buy into one experimental new approach.
> If you are relying on getting people to buy into two experimental new
> approaches (people have to get excited about both of those new paradigms
> before they'll get excited about your work), then you may have an extra
> high activation threshold to deal with.

In my view the two would combine to the interlinking of the approximately
same paradigm implemented at different levels of granularity.

One disadvantage to the current stack IMO would be that MinorFs/AppArmor
work only for local storage. Given that Tahoe has the same gap with E that
local filesystem access to $HOME did, I wondered if somehow adding support
to MinorFs for pseudo persistent process granularity access to Tahoe based
storage could perhaps help to close the gap by providing a second 'killer
benefit'.

Rob