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 <[email protected]> writes: > >> On Thu, Aug 21, 2014 at 2:06 PM, Camm Maguire <[email protected]> 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, > _______________________________________________ Gcl-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gcl-devel
