gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] selinux support


From: Camm Maguire
Subject: Re: [Gcl-devel] selinux support
Date: Thu, 21 Aug 2014 16:06:02 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Greetings!

Jerry James <address@hidden> writes:

> 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.

Thank you so much for this.  So I suppose this means this personality
bit will be completely meaningless?

I will have to read up on selinux 'policy' files.  I take it this means
an ordinary user will not be able to build gcl and or dependencies on
fedora.  I take it also that every application which unexec's an image
compiled by gcl will have to either be listed in this policy file or
some other one.  Do such things belong in the gcl source tree?

I do understand how the personality bit bypasses policy, but it seems
this was what was intended in supporting 'legacy' applications, and
gcl's approach certainly pertains to the traditional unix memory
management model.

It appears that all this obstruction is simply seeking assurance that
code has no predictable address relationship with data.  I'm wondering
how much randomness is required, and if gcl could not simply randomly
offset code when loading and satisfy all these concerns, and then be
left alone :-).

Take care,
-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

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