Re: [refpolicy] Patch: Create non_security_file_type attribute

["Christopher J. PeBenito" <cpebenito@tresys.com>]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.