Re: [Gcl-devel] selinux support

[daly]

Camm,

I'm fine with requiring changes to the SELinux permissions in order
to run the system. The NSA/SELinux team seems determined to try to
create a Harvard architecture on a Princeton architecture machine.
The idea of executing code from the heap or creating self-modifying
code? Only someone with evil intent would think of such things. Sigh.
Security people love to make a system "secure" by making it unusable
instead of attacking the real problem (badly written software).

Thanks for your time and effort on this.

Tim


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