Bug 178747 - rc.sysinit/bash denied execmod
rc.sysinit/bash denied execmod
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
MassClosed
:
: 178748 178749 178750 178751 178753 (view as bug list)
Depends On:
Blocks: fedora-ia64
  Show dependency treegraph
 
Reported: 2006-01-23 18:32 EST by Émeric Maschino
Modified: 2015-01-04 17:24 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-19 23:37:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Disable SELinux exec* checks on ia64 (1.01 KB, patch)
2006-01-26 15:01 EST, Stephen Smalley
no flags Details | Diff
Patch on which the prior patch depends (2.93 KB, patch)
2006-01-26 15:13 EST, Stephen Smalley
no flags Details | Diff
My audit.log file showing the irqbalance/hald denied read and search AVCs (7.43 KB, text/x-log)
2006-01-30 04:32 EST, Émeric Maschino
no flags Details
Enable exec* checking except for execmod for ppc32 and ia64 (1.48 KB, patch)
2006-02-01 08:05 EST, Stephen Smalley
no flags Details | Diff
Re-enable all exec* checking on ppc32, disable execmod only on ia64 (1.26 KB, patch)
2006-02-06 11:31 EST, Stephen Smalley
no flags Details | Diff
Enable exec* checking on all architectures (1.06 KB, patch)
2006-02-14 14:53 EST, Stephen Smalley
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 26090 None None None Never

  None (edit)
Description Émeric Maschino 2006-01-23 18:32:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ia64; en-US; rv:1.8) Gecko/20060103 Fedora/1.5-4 Firefox/1.5

Description of problem:
At bootup in permissive mode, I'm getting the following message that's also recorded in /var/log/messages:

Jan 24 01:12:21 zx6000 kernel: audit(1138061499.976:2): avc:  denied  { execmod
} for  pid=382 comm="rc.sysinit" name="bash" dev=dm-0 ino=3371840 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file

touch /.autorelabel doesn' solve the problem.

I don't know when this proble appears. I'm running Fedora since January 10th only and this problem was already there.

Version-Release number of selected component (if applicable):
selinux-policy-targeted 2.2.2-1, initscripts 8.21-1, bash 3.1-5

How reproducible:
Always

Steps to Reproduce:
1. Boot up Fedora Core IA-64 devel
2.
3.
  

Additional info:
Comment 1 Daniel Walsh 2006-01-24 17:18:32 EST
Uli, do you have any ideas?

Dan
Comment 2 Daniel Walsh 2006-01-26 13:52:41 EST
Stephen looks like we have a problem on ia64 with the toolchain or kernel.
Comment 3 Ulrich Drepper 2006-01-26 14:01:44 EST
The problem is that ia64 binaries have text relocations.  They should not but
many of them have.

I'll not be able to look at the reason for this for another couple of days so I
cc: Jakub.  This might be a toolchain issue.  It looked as if relocations are
applied to variables which are moved into .rodata or a similar section.  I.e.,
the TEXTREL flag seems adequate for these binaries.  But of course this
shouldn't happen.  I cannot remember that the ABI makes it impossible to create
TEXTREL-less binaries easily.

Regardless of what the reason is, for the time being the execmod part of the
tests should be disabled in the kernel, just like it happened for ppc.  If this
is a correctable toolchain problem we can remove the #ifdef once the toolchain
is fixed.  If this is an ABI problem (which I think it is *not*) then Intel has
to be motivated to fix the ABI and we can remove the #ifdef after a new
toolchain is widely used.  Otherwise we'll keep the test disabled forever.
Comment 4 Stephen Smalley 2006-01-26 14:21:18 EST
Do we want to keep adding #if !defined cases for architectures that are
problematic, or should the SELinux exec* checks be limited to a list of "known
good" architectures (and if the latter, what besides x86?).  
Note that not only execmod is disabled on ppc32 but also the other checks, as
they were encountering pervasive execmem denials too.

Comment 5 Stephen Smalley 2006-01-26 14:23:25 EST
BTW, anyone know the situation on x86_64?
Comment 6 Stephen Smalley 2006-01-26 15:01:47 EST
Created attachment 123735 [details]
Disable SELinux exec* checks on ia64
Comment 7 Ulrich Drepper 2006-01-26 15:07:01 EST
x86-64 has no problems.  In fact, the linker complains and does not finish its
work if a text relocation would be needed.
Comment 8 Stephen Smalley 2006-01-26 15:13:04 EST
Created attachment 123737 [details]
Patch on which the prior patch depends

This patch is already in -mm, so attachment 123735 [details] is relative to this patch.
This patch was a fix for bug 177663.
Comment 9 Daniel Walsh 2006-01-26 15:45:57 EST
*** Bug 178751 has been marked as a duplicate of this bug. ***
Comment 10 Dave Jones 2006-01-26 21:21:11 EST
applied to cvs, should be in tomorrows kernel build
Comment 11 Daniel Walsh 2006-01-27 00:02:49 EST
*** Bug 178753 has been marked as a duplicate of this bug. ***
Comment 12 Daniel Walsh 2006-01-27 00:04:02 EST
*** Bug 178750 has been marked as a duplicate of this bug. ***
Comment 13 Daniel Walsh 2006-01-27 00:05:25 EST
*** Bug 178749 has been marked as a duplicate of this bug. ***
Comment 14 Daniel Walsh 2006-01-27 00:53:10 EST
*** Bug 178748 has been marked as a duplicate of this bug. ***
Comment 15 Émeric Maschino 2006-01-30 04:30:31 EST
I confirm that the patch present in kernel 2.6.15-1.1878_FC5 disables the
execmod checks on IA-64, so I'm no more getting denied execmod and can now log
in in enforcing mode. However, from my audit.log file (attached), I'm getting
irqbalance/hald denied read and search AVCs. Should read and search checks be
disabled too? One thing I don't understand: in RHEL 4, checks are performed
normally (well, I suppose), and there's no denied execmod/search/read/write AVC
in the log file. Comment #3 from Ulrich Drepper explains that the problems I'm
currently experiencing with Fedora Core are due to IA-64 binaries having text
relocations. Wasn't it already the case in RHEL 4? If this is due a toolchain
problem, should I report it and against which package? I imagine that disabling
execmod checks for now, and perhaps search, read and write checks in the future
isn't a solution.
Comment 16 Émeric Maschino 2006-01-30 04:32:51 EST
Created attachment 123860 [details]
My audit.log file showing the irqbalance/hald denied read and search AVCs
Comment 17 Stephen Smalley 2006-01-30 09:59:32 EST
RHEL4 shipped with a) an older kernel (2.6.9-based) that didn't have some of
these checks (in particular no execmem or execmod checks) that were added later,
and b) an older targeted policy that confined fewer daemons.  RHEL4 was similar
to FC3 in its SELinux functionality, and that isn't expected to change much over
its lifetime IIUC, as the point of RHEL is stability, not bleeding edge development.

We wouldn't think of disabling search, read, and write file checking on IA64 -
those are generic permission checks that have no architecture or toolchain
specifity to them, and simply reflect the need to adjust policy to deal with
ongoing changes in the development tree code base and/or code paths that already
existed but weren't being exercised (and thus weren't being allowed by policy).
So your new issues are policy "bugs", not kernel bugs.
Comment 18 Daniel Walsh 2006-01-30 10:44:20 EST
selinux-policy-targeted-2.2-8.2 will fix the other AVC messages.
Comment 19 Stephen Smalley 2006-01-30 12:27:01 EST
I'd like to know whether the toolchain can be fixed readily.  If so, I won't
submit the patch included in the Fedora kernel to mainline.  If not, then I will
submit it for -mm and ultimately mainline.  But I have to wonder why this hasn't
come up from the Hardened Gentoo or Debian folks who use SELinux.
Comment 20 Stephen Smalley 2006-01-30 13:49:04 EST
I also would like clarification on whether disabling all the exec* checks is
necessary for ia64, or if only execmod is at issue (e.g. if the execmod had
passed, would we have later hit execmem as well)?

I looked at the PAX kernel patch, and it has an option to allow for text
relocations on ia64, alpha, and parisc to deal with "incorrectly created
applications".  Are alpha or parisc of concern to Fedora / RHEL?
Also, their option to disallow text relocations is only supported for ia64, x86,
and x86_64.  This goes back to my question of whether the SELinux exec* checks
(or at least execmod) should be limited to a specific list of known-good
architectures.
Comment 21 Émeric Maschino 2006-01-31 15:33:21 EST
I confirm that selinux-policy-targeted 2.2.9-1 solves the denied read and search
AVCs recorded in my audit.log file. I'm now getting various denied read, write
AVCs for hid2hci, but I don't know if they're related to those previously filed
in this bug.
Comment 22 Ulrich Drepper 2006-01-31 21:01:56 EST
> I also would like clarification on whether disabling all the exec* checks is
> necessary for ia64, or if only execmod 

It's only execmod.  Just as for ppc.
Comment 23 Émeric Maschino 2006-02-01 03:29:54 EST
(In reply to comment #22)
> > I also would like clarification on whether disabling all the exec* checks is
> > necessary for ia64, or if only execmod 
> 
> It's only execmod.  Just as for ppc.

What's needed to enable execmod checks: changes in the kernel, the toolchain,
the SELinux policy or a combination of these elements?
Comment 24 Stephen Smalley 2006-02-01 07:27:40 EST
(In reply to comment #22)
> > I also would like clarification on whether disabling all the exec* checks is
> > necessary for ia64, or if only execmod 
> 
> It's only execmod.  Just as for ppc.

No, on ppc32 they are all disabled, as I said in comment 4.  We had reports of
pervasive execmem denials on all (or at least many) binaries on ppc.  That was
discussed on rhselinux-list in Feb 2005 (Subject: Lots of problems with execmem
on powerpc).  Oddly, the original bugzilla cited in that thread is no longer
there.  Your recommendation at that time was to disable execmem on ppc32.

Comment 25 Stephen Smalley 2006-02-01 07:31:37 EST
(In reply to comment #23)
> (In reply to comment #22)
> > > I also would like clarification on whether disabling all the exec* checks is
> > > necessary for ia64, or if only execmod 
> > 
> > It's only execmod.  Just as for ppc.
> 
> What's needed to enable execmod checks: changes in the kernel, the toolchain,
> the SELinux policy or a combination of these elements?

Changes in the toolchain (or in ppc case, the ELF ABI itself, IIRC) are needed
to avoid triggering execmod and/or execmem checks on everything.  Then, once
that happens, we can re-enable the checking in the ia64 kernels (a kernel code
change), and then the existing policy should be fine. 
Comment 26 Jakub Jelinek 2006-02-01 07:35:09 EST
But it is not Feb 2005 any longer and FC5 on ppc32 is built with the since then
introduced -msecure-plt and therefore doesn't need execmem, at least not for
rebuilt binaries.
I'll look at the ia64 toolchain to see what's exactly going on and if it can
be fixed quickly to avoid generating DT_TEXTREL binaries.
Comment 27 Stephen Smalley 2006-02-01 07:55:44 EST
I see; well, no one told us that ppc32 situation had changed.  
So it would likely be useful to make a rawhide ppc32 kernel and rawhide ia64
kernel that re-enables all exec checking except execmod and see if that works ok.
I don't have either ppc32 or ia64 myself for testing.
Comment 28 Stephen Smalley 2006-02-01 08:05:17 EST
Created attachment 123958 [details]
Enable exec* checking except for execmod for ppc32 and ia64

This patch replaces attachment 123735 [details].	It disables only execmod on ppc32 and
ia64, re-enabling the other exec checks.  Like its predecessor, it is relative
to attachment 123737 [details] (which btw Andrew sent to Linus this morning, so
attachment 123737 [details] should be upstream RSN).
Comment 29 Dave Jones 2006-02-01 16:27:48 EST
indeed -git5 did have changes here, though they look odd. They introduce another
'rc' var with scope to the 'if' being ifdef'd, which shadows the rc var with
function-wide scope.

I changed it to use the function-wide variant, and removed the 2nd declaration,
thus..

--- linux-2.6.15.noarch/security/selinux/hooks.c~       2006-02-01
16:28:13.000000000 -0500
+++ linux-2.6.15.noarch/security/selinux/hooks.c        2006-02-01
16:30:30.000000000 -0500
@@ -2451,7 +2451,6 @@ static int selinux_file_mprotect(struct
        if (selinux_checkreqprot)
                prot = reqprot;

-#ifndef CONFIG_PPC32
        if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXECUTABLE) &&
           (vma->vm_start >= vma->vm_mm->start_brk &&
            vma->vm_end <= vma->vm_mm->brk)) {
@@ -2470,7 +2469,9 @@ static int selinux_file_mprotect(struct
                 * check ability to execute the possibly modified content.
                 * This typically should only occur for text relocations.
                 */
-               int rc = file_has_perm(current, vma->vm_file, FILE__EXECMOD);
+#if !defined(CONFIG_PPC32) && !defined(CONFIG_IA64)
+               rc = file_has_perm(current, vma->vm_file, FILE__EXECMOD);
+#endif
                if (rc)
                        return rc;
        }
@@ -2484,7 +2485,6 @@ static int selinux_file_mprotect(struct
                if (rc)
                        return rc;
        }
-#endif

        return file_map_prot_check(vma->vm_file, prot, vma->vm_flags&VM_SHARED);
 }


It'll be in tomorrows build
Comment 30 Ulrich Drepper 2006-02-01 17:42:45 EST
For PPC, we used to have the problem that the PLT had to be writable and
executable.  This was fixed.  I am not aware of any other problems.  I think
disabling everything was just overkill.

This means that the current rawhide kernel shouldn't need any #ifdefs for ppc. 
Maybe dwmw2 can test this before it goes into rawhide.  David?
Comment 31 Stephen Smalley 2006-02-02 07:40:07 EST
(In reply to comment #29)
> indeed -git5 did have changes here, though they look odd. They introduce another
> 'rc' var with scope to the 'if' being ifdef'd, which shadows the rc var with
> function-wide scope.

Looking at Linus' git tree, I see the "fix and cleanup mprotect checks" patch
applied, which actually removes a shadowed rc variable for the execmod check. 
That patch was the same as attachment 123737 [details].  Not sure what you mean by the above. 

Attachment 123958 [details] is then the patch that needs to be applied relative to -git to
 re-enable exec* checking other than execmod for ppc32 and to disable execmod
checks on ia64.  Attachment 123735 [details] is obsolete.

Comment 32 Stephen Smalley 2006-02-02 07:45:05 EST
-git5 contains no changes to selinux.
-git6 has attachment 123737 [details] merged.
Comment 33 Stephen Smalley 2006-02-02 07:55:38 EST
(In reply to comment #30)
> For PPC, we used to have the problem that the PLT had to be writable and
> executable.  This was fixed.  I am not aware of any other problems.  I think
> disabling everything was just overkill.
> 
> This means that the current rawhide kernel shouldn't need any #ifdefs for ppc. 
> Maybe dwmw2 can test this before it goes into rawhide.  David?

Attachment 123958 [details] (relative to -git6) removes the ppc32 ifdef for execmem and
moves the ppc32 ifdef for execstack/execheap/execmod to only cover execmod, so
that only execmod is disabled on ppc32.  Don't you still need execmod disabled
on ppc32 for text relocations?  Or is that also fixed now?

I'm also unclear on whether attachement 123958 (or similar patch re-enabling all
exec* checks on ppc32) is suitable for upstream, as not everyone will have the
rebuilt userland for ppc32, right?  In particular, FC4 ppc32 users could find an
unpleasant surprise if they ever re-base to a kernel that has that patch, and
non-Fedora ppc32 users could find an unpleasant surprise when they update to a
kernel including that change.  Thoughts?
Comment 34 Ulrich Drepper 2006-02-03 11:08:28 EST
> Don't you still need execmod disabled on ppc32 for text relocations?

Test relocations on ppc should now be as rare as on any other architecture. 
I.e., they should be dealt with individually.

But I really would like to see this tested before we push it out in a rawhide
kernel.  On the other hand, the number of people using the rawhide kernel for
ppc is low...


> I'm also unclear on whether attachement 123958 (or similar patch re-enabling
> all exec* checks on ppc32) is suitable for upstream,

Well, you need SELinux support to hit the problem.  This removes lots of/most
people from the equation.  I would say requiring a new toolchain is fine.  You
can still disable it with the boolean, right?  It just needs documentation.
Comment 35 Stephen Smalley 2006-02-06 11:26:19 EST
Looking at public devel cvs tree, it appears that the
selinux-mprotect-checks.patch there is a subset of attachment 123958 [details]; in
particular, it lacks the first hunk that removes the #ifndef CONFIG_PPC32 from
file_map_prot_check for the EXECMEM permission check, so execmem is still
disabled on ppc32 there.  It does re-enable execstack and execheap checking on
ppc32.  execmod is still disabled on ppc32 and ia64 there.  Per comment 34, it
would seem that execmod should be re-enabled on ppc32 as well, and only left
disabled on ia64 until the ia64 toolchain is corrected.

I will attach a new patch that replaces the current one that will re-enable all
checking on ppc32 and only disable execmod on ia64.  Ok?  but understand that I
have neither ppc32 nor ia64 hardware at my disposal presently to test.
Comment 36 Stephen Smalley 2006-02-06 11:31:57 EST
Created attachment 124265 [details]
Re-enable all exec* checking on ppc32, disable execmod only on ia64

This patch should replace the linux-2.6-selinux-mprotect-checks.patch in the
Fedora kernel, and obsoletes all prior patches for this bug.
Comment 37 David Woodhouse 2006-02-06 11:53:38 EST
I'll try another rawhide install tomorrow -- and if it doesn't prevent search
access to /lib64 this time, I'll actually try leaving selinux enabled for once. 

On the 64-bit kernel, all the exec* checking is already enabled; this only
changes the behaviour for 32-bit kernels to match the 64-bit kernel. And the
32-bit PPC CPUs will actually let you execute anything you can read _anyway_ :)
Comment 38 Jakub Jelinek 2006-02-08 02:39:40 EST
This is already fixed on the toolchain side, so once the whole distro is
rebuilt, it is kernel's turn.  Reassigning...
Comment 39 Stephen Smalley 2006-02-14 12:50:22 EST
(In reply to comment #38)
> This is already fixed on the toolchain side, so once the whole distro is
> rebuilt, it is kernel's turn.  Reassigning...

Current rawhide kernel has attachment 124265 [details] included, which re-enables all
checking on ppc32 and disables only execmod on ia64.  Should we drop the
conditional on ia64 as well, and thus enable all exec checking on all
architectures?  Or do we need to wait for FC6 for re-enabling execmod on ia64?
Comment 40 Ulrich Drepper 2006-02-14 14:10:55 EST
For rawhide we could drop the ia64 patch because the compiler is fixed and we
rebuild all packages.  In theory all should be well.  There is likely no better
way finding out whether there are more problems than to jump the gun.  So, I
support dropping the patch.
Comment 41 Stephen Smalley 2006-02-14 14:53:35 EST
Created attachment 124638 [details]
Enable exec* checking on all architectures

This patch replaces the prior one and enables exec* checking on all
architectures.
Patch is against 2.6.16-rc3.
Comment 42 Dave Jones 2006-02-16 00:45:39 EST
applied to cvs.  will be in builds higher than 2.6.15-1.1957_FC5
Comment 43 Émeric Maschino 2006-02-22 05:53:57 EST
I'm running latest kernel-2.6.15-1.1969_FC5.ia64.rpm on my Itanium workstation.
It seems that exec checkings are working fine now. I'm only getting AVCs
regarding swapon and hid2hci but I don't know if they're related to failed exec
checks or not. If needed, I can post my messages and audit.log files. Otherwise,
I think this bug can be closed.
Comment 44 Dave Jones 2006-10-16 13:36:32 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 45 Jon Stanley 2008-01-19 23:37:33 EST
(this is a mass-close to kernel bugs in NEEDINFO state)

As indicated previously there has been no update on the progress of this bug
therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue
still occurs for you and I will try to assist in its resolution. Thank you for
taking the time to report the initial bug.

If you believe that this bug was closed in error, please feel free to reopen
this bug.

Note You need to log in before you can comment on or make changes to this bug.