[apparmor] Selective AppArmor disable

[John Johansen]

On 07/06/2010 02:38 PM, Kees Cook wrote:
> On Mon, Jul 05, 2010 at 03:26:08PM +0100, Matt Zimmerman wrote:
>> This entry in the Alpha 2 release notes got me thinking:
>>
>>     Some AppArmor profiles, like the one from the CUPS printing system or
>>     MySQL, do not work due to a flaw in the kernel. As a workaround, disable
>>     the AppArmor profile for those services with "sudo aa-complain cups", or
>>     disable AppArmor altogether with "sudo update-rc.d apparmor disable".
>>     (599450)
>>
>> It occurred to me that it's easy to forget that one has done this, and
>> forego the default protections.  I think what we really want in a scenario
>> like this is something analogous to Apport's "ignore future crashes of this
>> program version", where the default behavior is automatically restored on
>> the next update.
>>
>> What do you think?
> 
> Sure, yeah.  It's not as pretty, but this has that effect:
> apparmor_parser -R /etc/apparmor.d/usr.sbin.cupsd
> 
> I.e. uploads it for just right now.
> 
> Maybe we could change the semantics of "aa-complain" to be temporary, and
> do "aa-complain --configs ..." to actually write it to disk.
> 
Hrmm I'm not sure that is enough, I think the state that it has been disabled
needs to persist at least until a new kernel/parser/profile is dropped in.

I could see having a directory like disable, used to just temporarily disable
profiles, and perhaps using the symlinks times tamp to determine whether
the profile should be reenabled.