[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/
gcl-2.6.8-selinux.patch
Description: Text Data