Re: v0 Separate tunables from booleans

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

On 08/25/2011 10:22 PM, Eric Paris wrote:
> On 08/25/2011 09:17 PM, Harry Ciao wrote:
>> Daniel J Walsh 写道:
> 
>>> The Fedora policy has removed all calls that do stuff like
>>> 
>>> allow XYZ_t { file_type -shadow_t }:file read;
>>> 
>>> Which generates hundreds/thousands of rules when run though the
>>> M4 Macro, since it writes a rule for each file_type except the
>>> shadow_t. Anywhere in policy that we use this construct has to
>>> be reworked and this shrunk the policy by 90%.  Your
>>> enhancement just adds another 5% reduction after this change.
>>> I sent a patch to refpolicy yesterday to fix the coreutils
>>> interfaces that we doing something like this.
>>> 
>>> 
>>> 
>> I don't know much about Fedora policy, but for upstream refpolicy
>> and toolchain my patch would contribute 45% size reduction for
>> raw policy and before I sent my patchset out for review I had not
>> seen your patch.
>> 
>> Anyway, it would be fantastic to have your patch to further
>> drastically reduce the raw policy size, the whole community would
>> benefit from each single contributor's effort like this.
> 
> Agreed.  I'm excited about both approaches (reducing the policy
> size by using attributes and eliminating needless unused portions
> of booleans). I'm glad to see Dan pushing his changes.  Once this
> patch set is finished I'll be very happy to see a further 5-6%
> reduction in the policy size of Fedora!
> 
> -Eric
> 
> -- 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.
> 
> 


I agree, I would like to take the patch to make tunables real, but we
need to have a similar level of diagnosis capability to what we have now.

The admin needs to know what the tunables are and needs to be able to
take an AVC and see if any tunable/boolean would allow the AVC.

If we had this, I would be racing towards the tunable.

I see this as two steps.

1.  Implement what we have now in booleans in tunables to shrink the
size of policy.
2.  Allow policy writers to define rules within tunables that is
currently not available in booleans.
    - Type Definitions
    - Assigning attributes

The major problems with #2 is I am not sure we have good tools to
analyze this type of policy from the audit2allow -> tunable that I
talk about above, to the security analysis that DOD needs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5XmKkACgkQrlYvE4MpobM0VACeNKcVtb597WkpThQ+hnLbC6M+
cTcAniR5MBqUGm0AUndTSrwNfbkATN1q
=DroM
-----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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux