Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching

[Sean]

On Mon, 11 Jun 2007 02:33:30 -0700 (PDT)
david@xxxxxxx wrote:

> Ok, you are proposing throwing out all the label handling that SELinux 
> does, including any caching. forgive me if I agree with the SELinux people 
> that this is a very bad idea.

Well presumably AA would be doing caching etc.. so that doesn't seem like
a problem.  The SELinux people seem to think that accepting AA into the
kernel and supporting path based security at all is a mistake.  I guess
I forgive you for agreeing with them ;)

> I thought the userspace component was what you were proposing instead of 
> doing the regex matching in the kernel. if this isn't it what exactly are 
> you proposing?

No.. i've said quite a few times now that i'm not talking about calling out
to userspace.  The entire discussion of regex matching is a completely
separate discussion.  It's either the right thing to do, or not.  But the
same issues in regard to regex matching apply whether AA is built on top
of SELinux or not.

> AA policies are defined in terms of regex expressions. you say that this 
> should be able to be done on top of SELinux somehow without changing the 
> policies. so somewhere, something needs to interpret the regex to see if 
> it matches the path. this needs to be either kernel code or userspace 
> code. you have ruled out kernel code and are now claiming that userspace 
> isn't needed.

For whatever it's worth, i'll repeat again.   The AA kernel extension would
be associating paths with labels (using regex, or not).  At that point all
policy decisions would be enforced by SELinux using standard SELinux policy
rules.   The SELinux policy would be a translated version of the AA policy
file.  The translation could of course happen in userland.

The net affect of all that... is that you get a version of SELinux which
can be configured with the user friendly AA policy file format.   And,
files won't need to carry around security labels with them.  I leave
the debate about whether that's a good idea in general to others.  But
from what i can tell, it's the only significant difference between
SELinux and AA.

Depending on the way it was implemented, its conceivable that users could
mix and match native SELinux policy with custom AA policies as they
saw fit.

Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/