[apparmor] [patch 05/21] Add stub rules to indicate compilation support for given features.

[John Johansen]

On 03/18/2014 04:21 PM, Steve Beattie wrote:
> On Mon, Mar 17, 2014 at 04:29:15PM -0700, john.johansen at canonical.com wrote:
>> Policy enforcement needs to be able to support older userspaces and
>> compilers that don't know about new features. The absence of a feature
>> in the policydb indicates that feature mediation is not present for
>> it.
>>
>> We add stub rules, that provide a none 0 start state for features that
>> are supported at compile time. This can be used by the kernel to
>> indicate that it should enforce a given feature. This does not indicate
>> the feature is allowed, in an abscence of other rules for the feature
>> the feature will be denied.
>>
>> Note: this will break the minimize tests when run with kernels that
>>       support mount or dbus rules. A patch to specify these features to
>>       the parser is needed to fix this.
>>
>> Signed-off-by: John Johansen <john.johansen at canonical.com>
> 
> This seems a bit goofy to me, squishing these into dfa rule
> structures. Is there a longer term plan to handle this more cleanly, or
> am I misunderstanding how this patch works?
> 
Hrmmm, no I don't have longer term plans to change how this works, except
to cleanup how/when these goofy rules are injected. Let me try to explain
this better. So either we do it in the dfa OR we have an external table to
consult.

Doing it in the dfa has the advantage of not needing an external table and
its overhead, when the policydb can easily encode this info. Basically the
policydb is layed out so that every rule class starts with a class identifier.


  start state[class ptrace] --> ptrace start state 


feeding the class id into the dfa gets you to what is the start state for
that class. It may be shared with other classes it doesn't matter. During
the unpack the kernel walks the first state to find the different states
for the classes it supports.

If there aren't any rules for that class in the dfa, the walk results in a
none matching start state for that class. This is what we actually are using
to determine if policy expects enforcement of that class, not the perm on
the start state.

If policy has rules for that class there will be a valid start state for
the class. The case that doesn't work is if a profile doesn't have a rule
for the class. But that doesn't mean that the profile doesn't expect the
class to be enforced, policy may have been written expecting that class
to be enforced but the profile doesn't have permission to use it.

For profiles that have rules of a given class this dummy rule isn't required.
But for profiles that don't have rules a dummy rule is required to generate
the start state. The permission on the rule is needed to keep dfa
minimization from removing it.

We could go with an external table of supported classes, but it would
require more work and require extra validation to get the same thing. And
it would also have to cope with our extended class support which will
allow us to support more classes than the base 255.

So I see it as more work for no gain.

What I do plan to do is improve the current rule object classes to remove
the need for the current kludge of generating these here. It will get
embedded in the classes and just happen correctly. I just never got that
far. The other change I plan for is the permission that will tag these
rules when we move to the newer extended permission set. It will be
AA_CONTINUE, which just tells the matching engine there is more match
to follow to find permissions.