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

Rob Meijer wrote:
> 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.

I aggree with you if you are trying to protect untrusted application
from the rest of the system.

I do not aggree if you are trying to protect rest of the system from
untrusted application.