Is there a SELinux tutorial for ISVs ?

Daniel J Walsh dwalsh at redhat.com
Mon May 9 15:32:26 UTC 2005


Mike Hearn wrote:

>On Thu, 28 Apr 2005 11:54:30 -0400, Daniel J Walsh wrote:
>  
>
>>Anyways I think we need more discussion on handling third party and user 
>>customization of policy outside of the current make tree stuff.
>>    
>>
>
>Sorry for posting so late ... one thing I'd also like to see is some
>formal rules for policy compatibility. For instance, if FC4 ships and says
>"Shared libraries with text relocations are no longer allowed by default"
>then this breaks things. If FC5 ships and now you need special tagging to
>connect to the X server, well ....
>
>  
>
The goal is to not change the fundamental securitylevel on policy/kernel 
updates.  If it does there
is a bug in policy.  Now we will be adding additional booleans in order 
to allow users to increase
the securitylevel.  So if a kernel gets added to a shipping OS 
(FC3/RHEL4) that supports an additional
access check, we need to allow this by default.   Same goes with adding 
additional policy rules.  For
example, I am trying to update the FC3/RHEL4 targeted policy with the 
improvements made in rawhide.
Any new booleans need to default to true. 

>(I don't know if this has actually happened or not yet but it seems to
>keep coming up)
>
>It may be decided that it's an acceptable price to pay for the additional
>security, or it may not. I don't think that discussion should happen
>now. But I think ISVs would feel a lot more secure if this sort of
>decision appeared not to be arbitrary and if there was some way to plan
>and work with the OS base policy writers.
>
>A basic system could be to have widely adopted (cross-distro) and
>documented security levels, ie:
>
>Level 1: Basic targetted - optin, only affects daemons, no restrictions
>         on anything else
>
>Level 2: Targetted + additional restrictions, execshield enabled (ie 
>         this is not just an SELinux thing), apps which require special
>         privs must have custom policy
>
>  
>
This is what booleans are for.

>Level 3: Strict
>
>or something similar to that. This means users can adjust their security
>level to adapt to what programs they run, and ISVs can say "Minimum
>Requirements: Level 2 or lower security level".
>
>thanks -mike
>
>--
>fedora-selinux-list mailing list
>fedora-selinux-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>


-- 





More information about the selinux mailing list