On Fri, 2008-07-18 at 13:26 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> James Carter wrote:
> > On Fri, 2008-07-18 at 11:49 -0400, Christopher J. PeBenito wrote:
> >> On Fri, 2008-07-18 at 11:42 -0400, James Carter wrote:
> >>> On Fri, 2008-07-18 at 10:15 -0400, Christopher J. PeBenito wrote:
> >>>> On Fri, 2008-06-27 at 14:55 -0400, James Carter wrote:
> >>>>> This patch eliminates the expansion of the file_type attribute (due to
> >>>>> the "-" set operation) for the *_non_security interfaces by creating a
> >>>>> non_security_file_type attribute.
> >>>>>
> >>>>> On my system the resulting binary policy is almost 20% smaller. The
> >>>>> difference is so large because there are over 1000 types labeled with
> >>>>> the file_type attribute.
> >>>> I'm hesitant to attach non_security_file_type to the files_type
> >>>> attribute, since its not clear to me that it makes conceptual sense.
> >>> The primary goal here is a smaller binary policy. But it still makes
> >>> sense conceptually to me because the security_file_type attribute is
> >>> never used by itself as far as I can tell. It is always used as
> >>> {file_type-security_file_type}.
> >>>
> >>>> In
> >>>> fact a sediff of the policy reveals that auidtd_log_t gains
> >>>> non_security_file_type while it already has security_file_type, which
> >>>> results in rule additions with this patch added.
> >>> That's not good. There are only a handful of types labeled with
> >>> security_file_type, I don't know how I missed that. Sorry.
> >>>
> >>> The following line is the problem: files_mountpoint(auditd_log_t).
> >>> So, a files_mountpoint_security interface would have to be created.
> >>>
> >>> It's not a big deal to me. If there is no interest in creating a
> >>> non_security_file_type attribute, I won't pursue this any farther.
> >> I think the binary policy size savings is a good enough reason to pursue
> >> it. Brainstorming for a second, another way to address this problem
> >> would be to change how checkpolicy handles negations. It could make a
> >> new attribute with the resultant type set from the negation;
> >
> > It would need to make sure that the resultant set is not already covered
> > by an attribute, or much of the value would be lost.
> >
> >> however,
> >> that might be bad for analysis since an attribute would magically appear
> >> out of nowhere.
> >
> > You already have that problem when analyzing a binary policy, since the
> > attribute names aren't preserved.
> >
> Speaking of which, I thought we were looking into adding that back in?
>
> It could help out tools like audit2why...
>
> Constraint violation, go though list of all attributes and see if one
> fixes the problem.
I'm not opposed, but requires a policy version bump and kernel patch.
Alternative is to make tools like audit2why read the modular policy like
modern setools does and thus have the attribute info from it.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
