Re: [Gcl-devel] selinux support

[Jerry James]

On Thu, Aug 21, 2014 at 2:06 PM, Camm Maguire <address@hidden> wrote:
> Thank you so much for this.  So I suppose this means this personality
> bit will be completely meaningless?

On future versions of Fedora, yes.  It may be a reasonable workaround
for other distributions for some time to come.  (And it will work on
Fedora 20 until it reaches End Of Life sometime next year.)

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

Yes and no.  Programs built by a user in his/her home directory and
executed only by that user can use some tricks to get around
system-wide policy (see below).  This is "safe" because any damage
from an exploit is confined to the user's own files.  The situation I
have to deal with as the maintainer of the gcl package for Fedora is
that the binaries are installed in /usr/bin, and have to work for all
users.

Package maintainers like me need some way to affect system-wide
SELinux policy for gcl and any programs built by gcl.  One way to do
that is to tell sysadmins that they need to do this (untested):

setsebool -P deny_execmem=0

- OR -

setsebool -P allow_execmem=1

depending on which boolean is provided.  But that will allow ALL
programs, not just those related to gcl, to mark memory as executable.
(Fedora actually defaults to allowing execmem, at the moment.  But
since sysadmins can change that, I ship SELinux policy to allow gcl to
run in either case.)  The policy files I provided allow a sysadmin to
specify that executables marked with the SELinux type gcl_exec_t are
allowed the execmem permission, and specifies that gcl and maxima both
be so marked.

If I'm building gcl in my home directory, for just my personal use, on
the other hand, I may have other options.  If my sysadmin has set
policy that allows some program, ANY program, to run with execmem
permission, I can hijack the corresponding type for my own purposes.
For example, if I know that lpr_exec_t provides execmem permission (I
don't, by the way), then I can either run my gcl-built programs in
one-shot mode like this:

runcon -t lpr_exec_t my_personal_gcl_program

or if I intend to keep an executable around for awhile, I can
permanently mark it, like so:

chcon -t lpr_exec_t my_personal_gcl_program

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

Yes, but it appears that the SELinux Powers That Be have decided that
READ_IMPLIES_EXEC is a security hole, and plan to close it.

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

Try running that by the SELinux folks and see what they say. :-)

By the way, I am not in any imaginable way an expert on SELinux, so
take all of the foregoing with a grain of salt.  Regards,
-- 
Jerry James
http://www.jamezone.org/