gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] selinux support


From: Jerry James
Subject: Re: [Gcl-devel] selinux support
Date: Thu, 21 Aug 2014 13:13:56 -0600

On Thu, Aug 21, 2014 at 11:18 AM, Camm Maguire <address@hidden> wrote:
> Greetings!  It has been known for some time that selinux by default
> stands in the way of gcl's traditional development paradigm: brk,
> compile, load, relocate, mprotect, execute, unexec, reexecute....  In
> particular, it forbids mprotecting (at least unrandomized) brk'ed memory
> PROT_EXEC.  Heretofore, the solution was to disable selinux on affected
> systems, but now it appears we have a better way.
>
> selinux appears to honor the READ_IMPLIES_EXEC personality bit.  It will
> turn off this bit on exec of children, so this bit must be handled a
> little differently than the existing gcl personality support of 1)
> turning on ADDR_NO_RANDOMIZE, and 2) on 32bit, turning on
> ADDR_LIMIT_3GB|ADDR_COMPAT_LAYOUT to get some immediate fixnum space, in
> which case we set and reexec with the child inheriting the new
> personality.

I can confirm that this works for Fedora 20.  However, it is going to
stop working in future versions of Fedora:

https://lists.fedoraproject.org/pipermail/devel/2014-January/194488.html

Also, this trick will not work on any Linux kernel booted with
checkreqprot=0, or any Lilnux system where the admin echoes zero into
/sys/fs/selinux/checkreqprot after boot.  I've been adding SELinux
policy files for gcl to the Fedora build since early 2009, with a few
tweaks over the years.  I sent a patch to this mailing list way back
then, but maybe it is time to share it again (attached).  HTH.
-- 
Jerry James
http://www.jamezone.org/

Attachment: gcl-2.6.8-selinux.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]