Bug 314901 - SELinux is preventing /lib/ld-2.6.90.so (initrc_t) "execstack" to <Unknown> (initrc_t).
Summary: SELinux is preventing /lib/ld-2.6.90.so (initrc_t) "execstack" to <Unknown> (...
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-02 00:54 UTC by Ben Liblit
Modified: 2008-01-30 19:07 UTC (History)
3 users (show)

Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-30 19:07:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

Description Ben Liblit 2007-10-02 00:54:13 UTC
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.


Comment 1 Ben Liblit 2007-10-02 00:54:13 UTC
Created attachment 213131 [details]
complete SELinux alert saved from setroubleshoot browser

Comment 2 Daniel Walsh 2007-10-02 04:10:19 UTC
What platform is this happening on?  This would be a major problem.

Usually a compiler problem.

Comment 3 Ben Liblit 2007-10-02 04:30:10 UTC
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 20:11:06 UTC
No my question is what hardware platform?

Comment 5 Ben Liblit 2007-10-09 21:56:47 UTC
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 13:35:29 UTC
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 14:12:13 UTC
cat /proc/<pid>/maps for one of the pids reported in the messages and attach the

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 18:47:24 UTC
(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

Comment 9 Ben Liblit 2007-10-16 19:03:46 UTC
(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 19:14:25 UTC
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 19:46:32 UTC
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 22:45:29 UTC
(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 22:49:31 UTC
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 04:17:50 UTC
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 13:04:02 UTC
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 18:28:17 UTC
Changed context in selinux-policy-targeted-3.0.8-24.fc8

Comment 17 Ben Liblit 2007-10-19 23:21:20 UTC
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 15:40:36 UTC
Just attach the audit.log and I will take a look.

Comment 19 Ben Liblit 2007-10-22 21:18:33 UTC
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 16:04:27 UTC
Ok I added fixes for this in selinux-policy-targeted-3.0.8-31.fc8

Comment 21 Daniel Walsh 2008-01-30 19:07:07 UTC
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.