Greeting! Sandip Ray <[EMAIL PROTECTED]> writes:
> Hi Camm, > > Is the solution then to disable SELinux in the machine? I guess I am fine > with doing that, but just wanted to make sure. This will certainly suffice, but less drastic measures should also. In order of severity: 1) disable 'strict' mode in SELinux (think you can do this with RH's kickstart). 2) Turn off allow_execmem (and possibly allow_execmod) from your strict policy (in /etc/selinux) and rebuild/reboot. Please let me know if problems persist. Take care, > > --- Sandip. > > On Fri, 9 Dec 2005, Camm Maguire wrote: > > \\Greetings! > \\ > \\OK, here is what I believe now to be the case -- the SELinux option > \\allow_execmem, which is 'active' on the bad box, is causing the > \\problem. All is well if one takes the drastic action of > \\ > \\sudo /bin/sh -c "/usr/sbin/setenforce 0" > \\ > \\but will probably allso work if one changes > \\ > \\/etc/selinux/strict/src/policy/domains/user.te:bool allow_execmem false; > \\ > \\to > \\ > \\/etc/selinux/strict/src/policy/domains/user.te:bool allow_execmem true; > \\ > \\and > \\ > \\sudo /bin/sh -c "cd /etc/selinux/strict/src/policy && make load" > \\ > \\though I have not confirmed this not wanting to hose the machine in > \\question. > \\ > \\The security people appear to persist in their (IMHO quite erroneous) > \\assumption that there is no legitimate need for an executable heap. > \\Tim Daly likely has further thoughts on this, but I saw the comment > \\again here: > \\ > \\http://copilotconsulting.com/mail-archives/selinux.2005/msg02006.html > \\ > \\Take care, > \\ > \\Camm Maguire <[EMAIL PROTECTED]> writes: > \\ > \\> Juho Snellman <[EMAIL PROTECTED]> writes: > \\> > \\> > <[EMAIL PROTECTED]> wrote: > \\> > > Greetings! I am a developer of GCL, which shares unexec with emacs. > \\> > > I have noticed on certain recent Fedora Core 4 machines, binaries > \\> > > produced with unexec cannot mprotect memory (allocated with brk) > \\> > > PROT_EXEC (returning EACCESS, i.e. permission denied), whereas > \\> > > binaries output by ld can do so just fine. This does not vary with > \\> > > exec-shield or randomize_va_space settings, and appears quite machine > \\> > > specific. The same binary which functions perfectly normally on one > \\> > > fc4 machine shows this failure only on another machine. I have as yet > \\> > > been unable to correlate this with dynamic library placement, or other > \\> > > settings in /proc/sys. > \\> > > \\> > Just a guess, but this might be related to SELinux. Do the machines > \\> > have differences in /etc/selinux/config? > \\> > > \\> > \\> Bingo! (I think) The config files are identical, but the problem > \\> machine has a 'strict' subdirectory with a host of files and options. > \\> Any idea of what I should look for herein, and what this could have to > \\> do with unexec vs ld? > \\> > \\> Thank you so much! > \\> > \\> > -- > \\> > Juho Snellman > \\> > > \\> > > \\> > > \\> > _______________________________________________ > \\> > Gcl-devel mailing list > \\> > Gcl-devel@gnu.org > \\> > http://lists.gnu.org/mailman/listinfo/gcl-devel > \\> > > \\> > > \\> > > \\> > \\> -- > \\> Camm Maguire [EMAIL > PROTECTED] > \\> ========================================================================== > \\> "The earth is but one country, and mankind its citizens." -- Baha'u'llah > \\> > \\> > \\> _______________________________________________ > \\> Gcl-devel mailing list > \\> Gcl-devel@gnu.org > \\> http://lists.gnu.org/mailman/listinfo/gcl-devel > \\> > \\> > \\> > \\ > \\ > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer