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

[Rob Meijer]

On Sat, January 30, 2010 10:39, Matej Kosik wrote:
> Karp, Alan H wrote:
>> Matej Kosik wrote:
>>> 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.
>>>
>> AppArmor will protect you if there is an exploitable flaw in the ocap
>> program.
>
> I would aggree if you said "can in some cases protect" instead of "will
> protect".
>
> I know that I make many errors. This is exactly why I appreciate
> object-capability languages. They enable me to mitigate the risk to
> acceptable level.
>
> (although it is still wise to be willing to pay bounties for remaining
> security flaws)
>
> Usage of AppArmor has non-zero cost. I am not sure, if it also has
> non-zero value (when used in conjunction with robust software systems
> written in some object-capability language). I am not aware of any
> studies that would prove or disprove my theory concerning AppArmor
> value. At the moment I rely on my intuition.

Usage of AppArmor indeed has non-zero cost, but than again it is more
light-weight than setuid+jails. Both suid+jails and AppArmor by themselves
miss the possibility of delegation of permissions, what I feel constitutes
most of the costs that these systems give rise to. MinorFs (for AppArmor)
and Powerbox technology (for suid+jails) mittigate some of these costs.

Using one of these mechanisms is absolutely essential when running e
programs on an Linux.

* $HOME and $TMP as only place to store persistent mutable data ARE a big
security hole for programs running on Linux that are trusted with
sensitive data or data (like the programs own serialisation) that is
essential for the integrity of the system.
* Basic /proc/$PID access controll makes it impossible for any process
running under a particular uid to keep secrets from other process running
under this uid.

The basic AppArmor profile I am suggesting is:
* No access to /proc/$PID period.
* No write access to the UID shared $HOME and $TMP

In my view it boils down to:

1) Programs written in ocap languages having need for persistent storage
can't just rely on what the ocap language provides to keep their
persistent data encapsulated.
2) If the program implements persistence, than this confidentiality issue
becomes an integrity issue.
3) Both suid+jail+powerbox and apparmor+minorfs are solutions to solve the
above, both with their own added cost and patterns of interaction.