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, -- Jerry James http://www.jamezone.org/ _______________________________________________ Gcl-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gcl-devel
