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

[John Johansen]

On 04/15/2014 03:42 PM, Seth Arnold wrote:
> On Tue, Apr 15, 2014 at 10:22:09AM -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>
>> Acked-by: Steve Beattie <steve at nxnw.org>
> 
> Acked-by: Seth Arnold <seth.arnold at canonical.com>
> -- at least if you're comfortable with the questions I've raised :)
> 
> Thanks
> 
>>
>> ---
>>  parser/parser_regex.c |   20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> --- 2.9-test.orig/parser/parser_regex.c
>> +++ 2.9-test/parser/parser_regex.c
>> @@ -673,6 +673,12 @@
>>  	return TRUE;
>>  }
>>  
>> +#define MAKE_STR(X) #X
>> +#define CLASS_STR(X) "\\d" MAKE_STR(X)
>> +
>> +static const char *mediates_mount = CLASS_STR(AA_CLASS_MOUNT);
>> +static const char *mediates_dbus =  CLASS_STR(AA_CLASS_DBUS);
>> +
> 
> Do we need to go to some effort to provide namespacing for these rules?
> For the future, we need to ensure e.g. that no AA_CLASS_FOO ever equals
> 47, or we'll encode a rule for "/".
> 
not a problem. These are used as the prefix for any match into the dfa.
No real matching is happening yet. Think of it as each class gets its
own dfa, except they are being stored in the same dfa?

Why because we can use dfa minimization to reduce and combine dfa states
from different classes when it is possible. Where not possible or perm
structures shouldn't overlap the states per class remain completely
separate.

One way of looking at it is the AA_CLASS is the namespacing

also currently the policydb and file dfas are separate, though they will
come together at some point.


>>  int process_profile_policydb(Profile *prof)
>>  {
>>  	int error = -1;
>> @@ -684,6 +690,20 @@
>>  	if (!post_process_policydb_ents(prof))
>>  		goto out;
>>  
>> +	/* insert entries to show indicate what compiler/policy expects
> 
> "show indicate", one or the other is redundant :)
> 
>> +	 * to be supported
>> +	 */
>> +
>> +	if (kernel_supports_mount) {
>> +		if (!aare_add_rule(prof->policy.rules, mediates_mount, 0, AA_MAY_READ, 0, dfaflags))
>> +			goto out;
>> +		prof->policy.count++;
>> +	}
>> +	if (kernel_supports_dbus) {
>> +		if (!aare_add_rule(prof->policy.rules, mediates_dbus, 0, AA_MAY_READ, 0, dfaflags))
>> +			goto out;
>> +		prof->policy.count++;
>> +	}
>>  	if (prof->policy.count > 0) {
>>  		prof->policy.dfa = aare_create_dfa(prof->policy.rules,
>>  						  &prof->policy.size,
>>
>>
>>