Please disable the SELinux execstack/relro checks before FC5 final

Stephen Smalley sds at tycho.nsa.gov
Fri Feb 17 14:43:18 UTC 2006


On Fri, 2006-02-17 at 09:26 -0500, Stephen Smalley wrote:
> On Fri, 2006-02-17 at 11:42 +0100, Arjan van de Ven wrote:
> > Hi,
> > 
> > I'm hereby asking to disable/remove the SELinux execstack/relro checks
> > before FC5 ships. The current state of affairs will only lead to people
> > using big-hammer approaches in disabling selinux or big chunks thereof
> > (based on "solutions" they find with google), which is worse than not
> > having this protection in the first place.
> > 
> > The technology is not finished yet. What I can imagine being useful is:
> > 1) having the security config tool do a scan for libs/binaries that are
> > not labeled correctly yet and present a dialog to add permissions,
> > including an explanation of what the consequences are
> > 2) a dbus message on failure so that the desktop can pop up a "<this
> > application> tried to use <this insecure library> which is most likely a
> > security risk. In case you downloaded this plugin deliberately, make
> > sure you want this" or something
> > 
> > As it is right now, it's just one more thing people will just disable
> > and hate selinux more for.  
> 
> Can you clarify exactly what you want here?  I assume you mean just
> allow-by-default, i.e. just enable booleans in the policy by default to
> allow these permissions while still giving people the option to disable
> them if they wish.  And what exact permissions are in view here:
> - execstack obviously
> - execheap?
> - execmod?  If so, to all file types under one boolean setting, and only
> to texrel_shlib_t under the opposite setting?
> - execmem?  

Another question is what domains are in view here, e.g. all domains
(such that allow_execstack permits execstack to every process rather
than just unconfined processes) or just unconfined_t (so that confined
daemons remain protected even if allow_execstack is enabled)?

-- 
Stephen Smalley
National Security Agency




More information about the fedora-devel-list mailing list