[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] [Gcl-devel] selinux support
Re: [Axiom-developer] [Gcl-devel] selinux support
Thu, 28 Aug 2014 14:24:44 -0500
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 -- 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'.
>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
>> 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,
|[Prev in Thread]
||[Next in Thread]|
- Re: [Axiom-developer] [Gcl-devel] selinux support,