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:
Uli, do you have any ideas? Dan
Stephen looks like we have a problem on ia64 with the toolchain or kernel.
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.
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.
BTW, anyone know the situation on x86_64?
Created attachment 123735 [details] Disable SELinux exec* checks on ia64
x86-64 has no problems. In fact, the linker complains and does not finish its work if a text relocation would be needed.
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.
*** Bug 178751 has been marked as a duplicate of this bug. ***
applied to cvs, should be in tomorrows kernel build
*** Bug 178753 has been marked as a duplicate of this bug. ***
*** Bug 178750 has been marked as a duplicate of this bug. ***
*** Bug 178749 has been marked as a duplicate of this bug. ***
*** Bug 178748 has been marked as a duplicate of this bug. ***
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.
Created attachment 123860 [details] My audit.log file showing the irqbalance/hald denied read and search AVCs
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.
selinux-policy-targeted-2.2-8.2 will fix the other AVC messages.
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.
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.
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.
> 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.
(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?
(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.
(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.
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.
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.
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).
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
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?
(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.
-git5 contains no changes to selinux. -git6 has attachment 123737 [details] merged.
(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?
> 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.
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.
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.
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_ :)
This is already fixed on the toolchain side, so once the whole distro is rebuilt, it is kernel's turn. Reassigning...
(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?
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.
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.
applied to cvs. will be in builds higher than 2.6.15-1.1957_FC5
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.
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.
(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.