[e-lang] E + MinorFs + AppArmor: adding Tahoe to the stack ?

[Matej Kosik]

Hi Rob,

Rob Meijer wrote:
> On Thu, January 28, 2010 20:02, Raoul Duke wrote:
>> On Thu, Jan 28, 2010 at 4:58 AM, Rob Meijer <capibara at xs4all.nl> wrote:
>>> On Tue, January 26, 2010 22:09, David Wagner wrote:
>>>> 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.
>>> 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.'
>>> ...
>>> 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'.
>> the question i have is: who really is the audience? my impression is
>> that the audience for security is something of a niche. so if you are
>> expecting Joe Ubuntu to beat a path to your door, that seems overly
>> hopeful. whereas if you are expecting something like the NSA to beat a
>> path to your door, well, that might have the possibility of success,
>> but also bring along its own issues :-).
> 
> My primary audience I guess would be people who want to build
> 'trustworthy' applications that can run on either Suse or Ubuntu (that is
> systems that come with AppArmor). The baseline is that without
> AppArmor/MinorFs you can not trust any application running as a particular
> user

I may be wrong but at present I disagree.

Let us take a concrete example:
http://altair.fiit.stuba.sk/mediawiki/index.php/SandboxedPing
This is, for me, a model example where object-capability programming
language provides us with everything we need to create 'trustworthy'
applications. In this case the word 'trustworthy' can be refined to
'cheaply auditable'.

The program is composed from two parts:
- Trusted/Host (which has superuser authority and must be therefore
audited. But since it is short, this security audit is cheap.)
- Untrusted/Guest (which is started in a sandbox, therefore it does not
have to be audited, but at runtime it receives all the necessary
capabilities so that it can potentially do the job it is expected to do.)

The "Trusted/Host" part is as complex as the security policy we want to
enforce. This is plausible.

I would like to ask you:
- Why would I gain something if I used also e.g. AppArmor?
  - Would it make security audit any simpler?
  - Would I be able to enforce a richer set of security policies?
  - Would it make development easier?

> and relying on shared mutable state provided by the $HOME and $TEMP
> directories UNLESS you can
> trust ALL applications running as that user. AppArmor+MinorFs allow you to
> trust a single application running as the same user as some other
> completely malicious application that is running at the same time with a
> minimum amount of confinement needed for the malware.