Re: [refpolicy] Patch: Create non_security_file_type attribute

[Daniel J Walsh <dwalsh@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> 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.
> 

of course there are trade-offs

# time sesearch --allow > /dev/null
WARNING: This policy contained disabled aliases; they have been removed.

real	0m1.495s
user	0m1.427s
sys	0m0.060s

# time sesearch --allow /etc/selinux/targeted/modules/active/*.pp >
/dev/null

real	0m10.666s
user	0m9.305s
sys	0m1.226s
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiA18kACgkQrlYvE4MpobPFsgCg5utU7uNNMU0r8vxMfvfHbOR9
GPAAn1eXVFRQDyyrFCahTOtmB+im5Wff
=hWfj
-----END PGP SIGNATURE-----

--
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.