address@hidden: Re: [Gcl-devel] Re: unexec and fedora core 4]

[root]

Emil,

If you can find the SELinux people please tell them to start using
GCL as a test case for their ideas. Apparently they seem to believe
that there is no reason for self-modifying code, executable heap
objects, stack execution, dynamic load/store/link, etc.

We in the lisp community are finding SELinux to be less than useful
and, as you can see, the general solution is to "turn it off".

While I agree with SELinux in principle it seems that every new
release adds yet another mindless breakage. 

The least they could do is issue an advisory bulletin on how to
make lisp work with their new restrictions each month. It would
save us a lot of debugging.

A frustrated maintainer,
Tim

------- Start of forwarded message -------
To: Juho Snellman <address@hidden>
Cc: Matt Kaufmann <address@hidden>, Sandip Ray <address@hidden>,
   address@hidden, address@hidden, root <address@hidden>,
   address@hidden
Subject: Re: [Gcl-devel] Re: unexec and fedora core 4
From: Camm Maguire <address@hidden>
Date: 09 Dec 2005 16:43:44 -0500
In-Reply-To: <address@hidden>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Content-Type: text/plain; charset=us-ascii

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 <address@hidden> writes:

> Juho Snellman <address@hidden> writes:
> 
> > <address@hidden> 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
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gcl-devel
> > 
> > 
> > 
> 
> -- 
> Camm Maguire                                          address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

- -- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah
------- End of forwarded message -------