Re: AppArmor Security Goal

[John Johansen <jjohansen@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]

On Sat, Nov 10, 2007 at 05:27:51PM -0800, david@lang.hm wrote:
> On Sat, 10 Nov 2007, Alan Cox wrote:
>
>>> but how can the system know if the directory the user wants to add is
>>> reasonable or not? what if the user says they want to store their
>>> documents in /etc?
>>
>> A more clear example is wanting to wrap a specific tool with temporary
>> rules. Those rules would depend on the exact file being edited at this
>> moment - something root cannot know in advance
>> (although with apparmor I guess mv $my_file apparmour_magic.name ; foo;
>> mv it back might work 8))
>
> the mechanism being desired was that the system administrator would setup a 
> restrictive policy and a user who wanted a more permissive policy would 
> have the ability to make it more permissive.
>
> this sort of thing is a disaster waiting to happen.
>
yep

> however, if App Armor sets things up so that there can be a system policy 
> that users cannot touch, but users can have a secondary policy that layers 
> over the system one to restrict things further it could be safe.
>
> if a sysadmin wants to have 'soft' and 'hard' limits of what a user can do, 
> they could put the 'hard' limits in the system policy (and the users 
> _cannot_ violate these limits), and then set the 'soft' limits in the users 
> default setup (similar to how .profile is set by default). if a user wants 
> to make things less restrictive they could edit or remove the per-user 
> policy, but would still not be able to violate the system policy.
>
> however, while this seems attractive, I'm not sure that madness isn't down 
> the road a little bit. since the users policy would only apply to 
> themselves, you have the situation that (DAC permissions permitting) the 
> files are available to other confined processes becouse they are running as 
> other users. this sort of thing will surprise people if the explinations 
> aren't done very carefully.
>
yes, the devil is in the details.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]