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

[Matej Kosik]

Hi,

Rob Meijer wrote:
> 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 do not understand why you state the AppArmor is *indispensable* in
case some application is run by a particular user where that application
relies on $HOME and $TEMP directories. Equally well---if you are
developing a new program---you can rely on object-capability langauges.

> 
>> 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 is true that the mentioned program is not run with user's authority.
It is run with superuser's authority. But this makes it even better
example. It shows how can we write programs that are started with
superuser's authority and still be safe.

> 
> 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.

This is intented. `sandboxed-ping' follows POLA so it cannot do what you
describe above.

> 
> 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.

I do not understand the argument that AppArmor is indispensable (even if
some process has to access files on the filesystem or interact with
other processes). Is there a security policy which cannot be enforced in
ocap-language (over untrusted modules written in this language)?
Obviously (for me) not, but I guess you do not concur.