[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: [Gcl-devel] Re: unexec and fedora core 4
From: |
Camm Maguire |
Subject: |
[Axiom-developer] Re: [Gcl-devel] Re: unexec and fedora core 4 |
Date: |
12 Dec 2005 22:14:29 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greeting!
Sandip Ray <address@hidden> 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 <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