[apparmor] [PATCH 3/8] add optional allow prefix to the language v3

[John Johansen]

On 09/18/2013 10:46 PM, Steve Beattie wrote:
> On Mon, Sep 16, 2013 at 11:37:28PM -0700, Steve Beattie wrote:
>> On Mon, Sep 16, 2013 at 05:06:51PM -0700, Seth Arnold wrote:
>>> On Mon, Sep 16, 2013 at 04:49:49PM -0700, Steve Beattie wrote:
>>>
>>> I think I'd expect the above to FAIL instead of PASS -- 'allow capability
>>> chown' followed by 'deny capability chown' doesn't make much sense. I know
>>> we've decided that 'deny' rules should subtract from the profile, but
>>> having two conflicting lines in one profile hurts my head.
>>>
>>> This feels complicated.
>>
>> I started typing up an email prepared to state that this patch was
>> extending behavior in the same direction as before, that 'deny'
>> rules always override 'allow' rules, and that this patch just adds
>> the ability to make explicit the implicit 'allow' in our regular
>> rules.
> 
> [Alright, here's the email I had started before.]
> 
> In this case, the behavior with capabilities is mimicking the already
> accepted behavior for file rules, which is that deny rules override
> allow rules (even ones without the 'allow' keyword).
> 
> This allows you to write something like:
> 
>     /usr/bin/** r,
>     deny /usr/bin/foo r,
> 
> which grants read access to everything under /usr/bin except
> /usr/bin/foo. For capabilities, it's less useful, but you could
> use it to express something like the following:
> 
>   allow capability,  # grants all capabilities...
>   deny capability sys_rawio sys_admin,  # ... except these that have
>                                         # been denied.
> 
> for a pretty loose profile.
> 
> All the 'allow' keyword is doing is making explicit the implicit
> 'allow' preceding every non-denial statement.
> 
>> What should happen in these cases? (Using without loss of generality
>> 'chown'...)
> 
> My understanding:
> 
>> profile a {
>>   allow capability chown,
>>   deny capability chown,
>> }
> 
> no access to chown capability,
> 
>> profile b {
>>   allow capability chown,
>>   deny capability,
>> }
> 
> no access to chown capability (or any other).
> 
>> profile c {
>>   allow capability,
>>   deny capability chown,
>> }
> 
> access to every capability except chown.
> 
>> profile aa {
>>   capability chown,
>>   deny capability chown,
>> }
> 
> no access to chown capability,
> 
>> profile bb {
>>   capability chown,
>>   deny capability,
>> }
> 
> no access to chown capability (or any other).
> 
>> profile cc {
>>   capability,
>>   deny capability chown,
>> }
> 
> access to every capability except chown.
> 
yep that matches my understanding of it too. Thanks for doing this