Created attachment 213131 [details]
complete SELinux alert saved from setroubleshoot browser

What platform is this happening on?  This would be a major problem.

Usually a compiler problem.

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.

No my question is what hardware platform?

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?

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.

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

(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.

(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.

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.  :-)

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

(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...?

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.  :-(

if you 

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

Then restart the guest, the AVC's should go away.

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.

Changed context in selinux-policy-targeted-3.0.8-24.fc8

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.

Just attach the audit.log and I will take a look.

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".

Ok I added fixes for this in selinux-policy-targeted-3.0.8-31.fc8

Bulk closing a old selinux policy bugs that were in the modified state.  If the
bug is still not fixed.  Please reopen.