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

[Rob Meijer]

On Fri, January 29, 2010 09:37, Matej Kosik wrote:
> 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
>

Quoted like this I would disagree myself ;-)

I originaly stated in the quoted sentence :  "AND relying on shared
mutable state provided by the $HOME and $TEMP directories".

> I may be wrong but at present I disagree.
>
> Let us take a concrete example:
> http://altair.fiit.stuba.sk/mediawiki/index.php/SandboxedPing

The application in this example is NOT actually running as the same user
as the possible malware, so by merit of running as an other user it can
exploit
the confinement offered by IBAC.

It does not rely on any data stored in the same mutable filesystem part
that is shared with any malware that may be running as this user.

The situation however I was refering to was applications that whould normaly
run in cooperation with other applications and would normaly need to use
something like $HOME or $TEMP. Those applications, running in the same uid
IBAC scope can't rely on their data storage without relying on all other
applications that may run under this same UID.

Just as in the language level we know the problems of static mutable
state, at the interprocess level we have this same problem if access to
$HOME and $TMP is available. If you don't remove this facility (As Ocap
languages do at the language level and AppArmor can do at the interprocess
level), you are in trouble when you want your 'cheaply auditable' property
to hold.

Once you remove $HOME and $TMP however, this would mean NO persistent
mutable state at all for processes. This will be fine for many programs,
but other programs need to have persistent mutable state.

Removing $HOME and $TMP and providing private alternatives can indeed also
be done using suid on all trustworthy applications. MinorFs/AppArmor does
the same without switching uid, following the same capability paradigms
for decomposition and delegation that E does.

Rob