Re: [Gcl-devel] selinux support

[Camm Maguire]

Greetings!

Tim -- are you ok now with 

1) the selinux workaround with fedora lifetime of ~ 1 year and 
2) the package maintainer/end user workarouns mentioned below

for axiom on selinux systems using gcl 2.6.11pre?

I really don't know what else to do.  If someone is using a computer
owned by someone else who does not want anyone to allocate executable
memory, they are going to have to get some sort of special permission if
gcl is going to work.  I imagine ld.so has been granted said permission
in similar fashion.

What would be fantastic would be a bit we could set in gcl unexeced
binaries to specify the required permissions for *all* gcl programs in
one place.  Then the sysadmin people could permit/deny to their heart's
content.  I suppose this is what chcon does, but I suppose there is no
trans system standardization to 'gcl_exec_t'.

Take care,



Jerry James <address@hidden> writes:

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

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