Bug 314901 - SELinux is preventing /lib/ld-2.6.90.so (initrc_t) "execstack" to <Unknown> (initrc_t).
SELinux is preventing /lib/ld-2.6.90.so (initrc_t) "execstack" to <Unknown> (...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-01 20:54 EDT by Ben Liblit
Modified: 2008-01-30 14:07 EST (History)
3 users (show)

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


Attachments (Terms of Use)
complete SELinux alert saved from setroubleshoot browser (2.09 KB, text/plain)
2007-10-01 20:54 EDT, Ben Liblit
no flags Details
output of "ausearch -i -sc mprotect -sv no" (63.97 KB, text/plain)
2007-10-16 15:14 EDT, Ben Liblit
no flags Details
audit.log for networking-related AVC denials (8.70 KB, text/plain)
2007-10-22 17:18 EDT, Ben Liblit
no flags Details

  None (edit)
Description Ben Liblit 2007-10-01 20:54:13 EDT
I'm seeing repeated SELinux denials regarding "execstack" permission and
/lib/ld-2.6.90.so.  They are coming in multiple times per second.  Combine these
with the SELinux notification applet and it's hard to get any useful work done
while notification bubbles keep popping up on top of my other windows.

I've tried relabeling the entire file system, but that makes no difference.

I'll attach a complete SELinux alert to this bug report.

glibc-2.6.90-15
selinux-policy-3.0.8-14.fc8
selinux-policy-targeted-3.0.8-14.fc8
Comment 1 Ben Liblit 2007-10-01 20:54:13 EDT
Created attachment 213131 [details]
complete SELinux alert saved from setroubleshoot browser
Comment 2 Daniel Walsh 2007-10-02 00:10:19 EDT
What platform is this happening on?  This would be a major problem.

Usually a compiler problem.
Comment 3 Ben Liblit 2007-10-02 00:30:10 EDT
The host "machine" is really a VMware virtual machine.  It started as a Fedora 8
Test 2 image packaged by the kind folks at ThoughtPolice:
<http://www.thoughtpolice.co.uk/vmware/>.  I have subsequently upgraded RPMs as
suggested by the standard Fedora package updater tools.  (I assume that means
I've picked up bits and pieces from Rawhide.)

I'm not compiling anything myself, so if there's a compiler problem, then that
problem arose on Fedora's side.

I *think* that this problem did not occur in the original F8T2 VMware virtual
machine.  Unfortunately I'm not sure when it did first appear.  I might be able
to recover that information by looking through /var/log/messages.*.  I cannot do
that right now, but I ought to be able to do that in the next few days if you
think it would be helpful.
Comment 4 Daniel Walsh 2007-10-09 16:11:06 EDT
No my question is what hardware platform?
Comment 5 Ben Liblit 2007-10-09 17:56:47 EDT
The *real* hardware that the VMware virtual machine is running on is a dual-core
Intel(R) Pentium(R) D CPU 3.20GHz.  The real operating system running on this
real hardware is CentOS 4.3, using kernel-2.6.9-55.0.6.EL.i686.

From inside the Fedora 8 Test 2 VMware virtual machine, "/proc/cpuinfo" reports
that it sees a single-core Intel(R) Pentium(R) D CPU 3.20GHz.

Does that answer the "hardware platform" question, or do you need more details
about some other aspect of the real or virtual hardware?
Comment 6 Daniel Walsh 2007-10-10 09:35:29 EDT
Yes that is plenty.

If you set allow_execstack does the machine calm down any?

setsebool -P allow_execstack 1

This seems like some bad interaction between vmware and the Linux Kernel.
Comment 7 Stephen Smalley 2007-10-10 10:12:13 EDT
cat /proc/<pid>/maps for one of the pids reported in the messages and attach the
output.

yum install audit
/sbin/auditctl -a exit,always -S mprotect
{generate some of these denials}
/sbin/ausearch -i -sc mprotect -sv no > log
{attach log}
/sbin/auditctl -D
Comment 8 Ben Liblit 2007-10-16 14:47:24 EDT
(In reply to comment #6)

Yes, if I run "setsebool -P allow_execstack 1" then the machine calms down
completely.  No more SELinux denials.

If I then run "setsebool -P allow_execstack 0", the SELinux denials immediately
return.
Comment 9 Ben Liblit 2007-10-16 15:03:46 EDT
(In reply to comment #7)

I have tried to capture /proc/<pid>/maps for one of the processes reported in
the messages, but I cannot.  No process reported in a message is still alive and
running on my box.  Even though I see these messages every few seconds, the
processes being spawned are apparently short-lived.  I've checked every single
pid (with a little help from sed), and not one of them corresponds to a live
process.  I can't even tell what commands are actually being run, since the
SELinux audit messages only refer to ld-2.6.90.so.
Comment 10 Ben Liblit 2007-10-16 15:14:25 EDT
Created attachment 229151 [details]
output of "ausearch -i -sc mprotect -sv no"

(In reply to comment #7)

I've attached the trailing portion of the output of "/sbin/ausearch -i -sc
mprotect -sv no" as requested in comment #7.  Surprisingly, the complete output
goes back nearly a month.  I'm not sure why that is, given that I only ran the
suggested "auditctl" commands a few minutes ago.  Perhaps some audit tracing is
on by default?	{shrug}

Looking at the log more closely, notice that the denials come in about once
every ten seconds.  Perhaps there's a single problematic process that is being
spawned every ten seconds?  It certainly doesn't seem that this denial is
appearing for *every* process launch; I've tried running various commands
myself and have been unable to trigger denials.  So that suggests that there's
just one bad actor somewhere that we need to track down, rather than a
system-wide problem.

It also appears that my original claim of multiple messages per second was an
overstatement.	The logs show it's more line one message every ten seconds. 
Sorry for overstating the problem.  It's still pretty darn annoying, even at
just one message every ten seconds.  :-)
Comment 11 Stephen Smalley 2007-10-16 15:46:32 EDT
Running ldd on a program or shared library that requires executable stack would
trigger that.  
What's running in inirc_t on your system?
ps -eZ | grep initrc_t
Comment 12 Ben Liblit 2007-10-16 18:45:29 EDT
(In reply to comment #11)
> What's running in inirc_t on your system?

I see two processes: vmware-guestd and NetworkManagerDispatcher.  Sending
SIGSTOP to vmware-guestd stops the SELinux denials.  Sending SIGCONT causes them
to appear again.  Sending SIGSTOP to NetworkManagerDispatcher has no effect.  So
vmware-guestd is looking pretty guilty.

I realize that vmware-guestd is not a Fedora-provided program, so if you wanted
to stop reading and close this bug right now I wouldn't blame you.  But now that
I've got things narrowed down, perhaps I can push along a bit further.

strace on vmware-guestd reveals that it runs "ldd
/usr/lib/vmware-tools/bin32/vmware-user" about once every ten seconds.  Running
this command by hand produces the same SELinux denial I originally reported.

"execstack --query /usr/lib/vmware-tools/bin32/vmware-user" reports "X": this
binary is explicitly marked as requiring an executable stack.

I observe that my Fedora 7 virtual machine has allow_execstack on, which is why
this problem did not appear earlier.  Fedora 8 Test 2 has tightened the default
security settings, and VMware hasn't caught up yet.

While this is clearly not Fedora's bug, I'd appreciate any guidance as to the
recommended course of action.  I could use "execstack --clear-execstack" to mark
the binary as not needing an executable stack and hope that it still manages to
run correctly without it.  I could turn off allow_execstack globally, but that
seems overly broad and therefore risky.  Any other good options?

Of course I should also report this to VMware.  But I have my doubts as to
whether they will respond in a timely manner if I just go through the regular
support channels.  F8T2 has got to be low on their support priority list.  And
the "Create Support Request" link on their web page leads to a 404 error anyway.
 Drat.  :-(  I don't suppose Red Hat has any favored support contacts at VMware...?
Comment 13 Ben Liblit 2007-10-16 18:49:31 EDT
Actually, "execstack --clear-execstack /usr/lib/vmware-tools/bin32/vmware-user"
doesn't help much.  Now I get repeated SELinux denials when vmware-user tries to
make its stack executable.  Feh.  :-(
Comment 14 Daniel Walsh 2007-10-17 00:17:50 EDT
if you 

#chcon -t vmware_host_exec_t /usr/sbin/vmware-guestd

Then restart the guest, the AVC's should go away.
Comment 15 Stephen Smalley 2007-10-17 09:04:02 EDT
If that resolves your problem, to make that label "stick" across relabels,
you'll want to add it to your local file contexts mapping, ala:
/usr/sbin/semanage fcontext -a -t vmware_host_exec_t /usr/sbin/vmware-guestd

Then a subsequent relabel won't reset it to the policy default.


Comment 16 Daniel Walsh 2007-10-17 14:28:17 EDT
Changed context in selinux-policy-targeted-3.0.8-24.fc8
Comment 17 Ben Liblit 2007-10-19 19:21:20 EDT
My Fedora 8 Test 2 system got into a messy state, but I've now set up a Fedora 8
Test 3 virtual machine.  After updating to selinux-policy-targeted-3.0.8-24.fc8
and performing a full system relabel, I confirm that the AVCs originally
reported here no longer appear.

Thank you both for your expert help, especially given the involvement of
non-Fedora-provided software.

By the way, I am now seeing AVCs relating to VMware log files and various
networking tools: /sbin/{ip,ifconfig,dhclient,arping}.  There are 19 in rapid
sequence from /sbin/ip alone.  Should we broaden this bug report to cover VMware
+ SELinux issues more generally?  Should I file a new report about these AVCs? 
Should I not report these to you at all because they are VMware's problem, not
Fedora's problem?  Please let me know how you wish to proceed.
Comment 18 Daniel Walsh 2007-10-22 11:40:36 EDT
Just attach the audit.log and I will take a look.
Comment 19 Ben Liblit 2007-10-22 17:18:33 EDT
Created attachment 234551 [details]
audit.log for networking-related AVC denials

The attached "audit.log" is representative of the networking-related AVC
denials I'm seeing.  Mostly /sbin/ip, but one /sbin/arping and one
/sbin/dhclient as well.  I've seen this with /sbin/ifconfig in the past, but
I'm not seeing that now.  {shrug}

Observe that the path involved is consistently "/var/log/vmware-tools-guestd".
Comment 20 Daniel Walsh 2007-10-23 12:04:27 EDT
Ok I added fixes for this in selinux-policy-targeted-3.0.8-31.fc8
Comment 21 Daniel Walsh 2008-01-30 14:07:07 EST
Bulk closing a old selinux policy bugs that were in the modified state.  If the
bug is still not fixed.  Please reopen.

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