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; however,
that might be bad for analysis since an attribute would magically appear
out of nowhere.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
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.
