Description of problem: type=AVC msg=audit(1196050098.540:31): avc: denied { read } for pid=2201 comm="rpc.idmapd" name="net" dev=proc ino=4026531865 scontext=system_u:system_r:rpcd_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=dir type=SYSCALL msg=audit(1196050098.540:31): arch=c000003e syscall=2 success=no exit=-13 a0=2aaaaacb45e8 a1=2 a2=0 a3=0 items=0 ppid=1 pid=2201 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rpc.idmapd" exe="/usr/sbin/rpc.idmapd" subj=system_u:system_r:rpcd_t:s0 key=(null) Version-Release number of selected component (if applicable): kernel-2.6.24-0.42.rc3.git1.fc9 nfs-utils-1.1.0-6.fc8 selinux-policy-targeted-3.0.8-56.fc8 How reproducible: Always Steps to Reproduce: 1./etc/rc.d/init.d/nfs start 2. 3. Actual results: As above Expected results: Nothing special Additional info:
You can allow this for now by executing # audit2allow -M mypol -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.0.8-62.fc8
Still seeing the problem. Additional Information Source Context system_u:system_r:rpcd_t Target Context system_u:object_r:proc_net_t Target Objects None [ dir ] Affected RPM Packages nfs-utils-1.1.0-6.fc8 [application] Policy RPM selinux-policy-3.1.2-1.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name sdv Platform Linux sdv 2.6.24-0.43.rc3.git1.fc9 #1 SMP Mon Nov 26 07:50:09 EST 2007 x86_64 x86_64 Alert Count 9 First Seen Mon Nov 26 10:27:32 2007 Last Seen Wed Nov 28 19:38:45 2007 Local ID 5966f5af-4fa8-4fff-8237-7b6acb7ae7a6 Line Numbers Raw Audit Messages avc: denied { read } for comm=rpc.idmapd dev=proc egid=0 euid=0 exe=/usr/sbin/rpc.idmapd exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=net pid=2231 scontext=system_u:system_r:rpcd_t:s0 sgid=0 subj=system_u:system_r:rpcd_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:proc_net_t:s0 tty=(none) uid=0
That does not make sense? Are you sure the update was successful? rpm -q selinux-policy selinux-policy-3.1.2-1.fc9 audit2why < /tmp/t avc: denied { read } for comm=rpc.idmapd dev=proc egid=0 euid=0 exe=/usr/sbin/rpc.idmapd exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=net pid=2231 scontext=system_u:system_r:rpcd_t:s0 sgid=0 subj=system_u:system_r:rpcd_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:proc_net_t:s0 tty=(none) uid=0 Was caused by: Unknown - would be allowed by active policy Possible mismatch between this policy and the one under which the audit message was generated. Possible mismatch between current in-memory boolean settings vs. permanent ones.
Maybe not. Just tried to reinstall the policy, got a bunch of exceptions like: libsepol.check_assertion_helper: assertion on line 0 violated by allow unconfined_crond_t mailman_queue_t:process { fork sigchld sigkill sigstop signull signal ptrace getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit rlimitinh setcurrent setkeycreate setsockcreate }; Cannot allocate memory. libsepol.check_assertion_helper: assertion on line 0 violated by allow rpm_script_t unconfined_crond_t:process { sigchld }; Cannot allocate memory. libsepol.check_assertions: 426 assertion violations occured Cannot allocate memory. libsemanage.semanage_expand_sandbox: Expand module failed Cannot allocate memory. semodule: Failed! What is that??
Created attachment 271281 [details] output of policy update This is what happens when I try and rpm -ivh --force the current policy rpms.
Those messages indicate that a neverallow rule in the policy (a policy assertion on what should not be allowed by any combination of allow rules) was violated by some allow rule. Bug in policy. The "Cannot allocate memory" part is bogus. libsemanage is appending strerror(errno) to the base message provided by libsepol, and apparently errno isn't get set/cleared properly there. Looks like this one just got reported on fedora-selinux-list too by Tom London.
Oddly though I don't see it here. Updating selinux-policy* on a devel box. But it is an x86, not x86_64.
BTW, to skip the neverallow checking, add expand-check = 0 to /etc/selinux/semanage.conf
Ok, reproduced on x86_64.
Hmm...re-installed libse* and it stopped happening.
So, Dan, does that policy violate a neverallow or not? The neverallows I see that would be applicable are: neverallow { domain unlabeled_t } ~{ domain unlabeled_t }:process *; neverallow ~{ domain unlabeled_t } *:process *; But those should only trigger if the unconfined_crond_t type lacked the domain attribute in the policy. Which would be a policy bug. BTW, I don't believe those kinds of assertions really belong in the shipped policy - they are essentially bug checking and they take a long time to check, thereby making semodule much slower. So I'd recommend using one set of neverallows on your policy devel box and a different set for production. In fact, one might argue that we shouldn't be shipping any neverallows by default in the stock policy.
(In reply to comment #10) > Hmm...re-installed libse* and it stopped happening. > > Still happening for me, and after yum removing then reinstalling, the whole process stalls while installing selinux-policy-targeted: Running Transaction Installing: libsemanage ######################### [1/5] Installing: policycoreutils ######################### [2/5] Installing: selinux-policy ######################### [3/5] Installing: selinux-policy-targeted ######################### [4/5] [ nothing...] bash(2794)───yum(2923)───sh(2933)───sh(2935)───semodule(2936) # strace -fp 2936 Process 2936 attached - interrupt to quit write(2, "assertion on line 0 violated by "..., 299 not sure what it's waiting for.
Bug 368271 explains the hang - yum doesn't deal well with too much output from a scriptlet. The assertion failures themselves are a separate issue. I'd suggest re-assigning to libsepol, as we seem to be getting inconsistent assertion checking there - we should either always get this reported on this policy or never, not intermittently. Joshua?
So, I'm trying to catch up on this. We are getting intermittent assertion violations for the same policy? That is very strange, the soonest I'll be able to look at this is Monday.
That's what I've experienced, although it sounds like others are consistently getting the assertion failure? The policy itself looks bad - dismod and apol on the unconfined.pp file shows unconfined_crond_t as having no attributes at all. Don't know if that matches what was in the source that was used to compile it or if this represent a problem in the module compiler. It certainly should trigger the assertion/neverallow failure in all instances.
Did selinux-policy-3.2.1-1 fix this problem?
Steve, wouldn't removing the neverallow rules, allow people to install bad pp files?
3.1.2 policy was bad. But it seems to have triggered other problems.
Initial issue seems to be fixed, now getting: avc: denied { getattr } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 exe="/usr/sbin/rpc.mountd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 path="/dev/kvm" pid=2798 scontext=system_u:system_r:nfsd_t:s0 sgid=0 subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=chr_file tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0
Just did a yum update to latest rawhide: SELinux is preventing rpc.idmapd (rpcd_t) "write" to <Unknown> (proc_t) Additional Information Source Context system_u:system_r:rpcd_t Target Context system_u:object_r:proc_t Target Objects None [ file ] Affected RPM Packages Policy RPM selinux-policy-3.2.3-2.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name sdv Platform Linux sdv 2.6.24-0.107.rc5.git3.fc9 #1 SMP Fri Dec 14 12:15:01 EST 2007 x86_64 x86_64 Alert Count 1 First Seen Mon Dec 17 21:17:15 2007 Last Seen Mon Dec 17 21:17:15 2007 Local ID 5ca6481b-b939-4cdc-9928-2151dd848fee Line Numbers Raw Audit Messages avc: denied { write } for comm=rpc.idmapd dev=proc name=channel pid=2213 scontext=system_u:system_r:rpcd_t:s0 tclass=file tcontext=system_u:object_r:proc_t:s0
Syslog entry: Dec 17 21:19:59 sdv rpc.idmapd[2213]: nfsdreopen: Opening '/proc/net/rpc/nfs4.nametoid/channel' failed: errno 13 (Permission denied)
Is this something new
Currently policy allows rpcd to write to sysctl, but not to proc. There is also a labeling problem in the kernel. This file should be labeled proc_net_t not proc_t. This has been reported in a different bug and Eric is looking into it.
Still broken (for write). Additional Information Source Context system_u:system_r:rpcd_t Target Context system_u:object_r:proc_t Target Objects None [ file ] Affected RPM Packages Policy RPM selinux-policy-3.2.4-5.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name sdv Platform Linux sdv 2.6.24-0.107.rc5.git3.fc9 #1 SMP Fri Dec 14 12:15:01 EST 2007 x86_64 x86_64 Alert Count 18 First Seen Mon Dec 17 21:17:15 2007 Last Seen Thu Dec 20 11:38:42 2007 Local ID 5ca6481b-b939-4cdc-9928-2151dd848fee Line Numbers Raw Audit Messages avc: denied { write } for comm=rpc.idmapd dev=proc name=channel pid=2216 scontext=system_u:system_r:rpcd_t:s0 tclass=file tcontext=system_u:object_r:proc_t:s0
But this is a kernel bug /proc/net is labeled proc_net_t by policy. But the kernel is reporing this as a proc_t error. Need to fix the kernel before I fix the rpcd_t ability to write to proc_net_t.
What is the other bz # ?
This one. Since I could not find another.
A fix for this issue has been merged upstream. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b1aa5301b9f88a4891061650c591fb8fe1c1