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.
--
James Carter <jwcart2@xxxxxxxxxxxxx>
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.
