Are you running with ext4?

Yes

[root@viklef ~]# uname -r
2.6.27.12-170.2.5.fc10.x86_64
[root@viklef ~]# mount
/dev/mapper/vg00-lvRoot on / type ext4 (rw)
/proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
/dev/dm-5 on /home type ext3 (rw)
tmpfs on /tmp type tmpfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
gvfs-fuse-daemon on /home/matej/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=matej)
[root@viklef ~]#

These are issues with the kernel.  I believe there is an update on the way to fix this.

ext4 things is CAP_SYS_RESOURCE not CAP_SYS_ADMIN....

huh, this wants sys_admin, sys_rawio, and cap_sys_resource....

ahhhh, did your OOM killer pop just seconds later?  Looks like these 3 called together is in the OOM killer when determining how valuable a given task is when looking for one to shoot.  upstream this is fixed by just not outputting the denial message.  I don't really see the need to backport it for such a corner case...

(In reply to comment #6)
> ahhhh, did your OOM killer pop just seconds later?  Looks like these 3 called
> together is in the OOM killer when determining how valuable a given task is
> when looking for one to shoot.  upstream this is fixed by just not outputting
> the denial message.  I don't really see the need to backport it for such a
> corner case...

I don't know -- the only OOM killer I had recently was when tried pidgin in valgrind. It might be caused by that.

ok, I'm going to close this as fixed upstream.  2.6.29 should keep these denials from popping out during an oom kill calculation.  If you ever see this type of thing and don't see an oom kill in the vicinity you can reopen.

*** Bug 483462 has been marked as a duplicate of this bug. ***

And this is duplicate of this bug as well, right?


Souhrn:

SELinux is preventing arping (netutils_t) "sys_module" netutils_t.

Podrobný popis:

SELinux denied access requested by arping. It is not expected that this access
is required by arping and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Povolení přístupu:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Další informace:

Kontext zdroje                system_u:system_r:netutils_t:s0-s0:c0.c1023
Kontext cíle                 system_u:system_r:netutils_t:s0-s0:c0.c1023
Objekty cíle                 None [ capability ]
Zdroj                         arping
Cesta zdroje                  /sbin/arping
Port                          <Neznámé>
Počítač                    viklef.ceplovi.cz
RPM balíčky zdroje          iputils-20071127-6.fc10
RPM balíčky cíle           
RPM politiky                  selinux-policy-3.5.13-41.fc10
Selinux povolen               True
Typ politiky                  targeted
MLS povoleno                  True
Vynucovací režim            Enforcing
Název zásuvného modulu     catchall
Název počítače            viklef.ceplovi.cz
Platforma                     Linux viklef.ceplovi.cz
                              2.6.27.12-170.2.5.fc10.x86_64 #1 SMP Wed Jan 21
                              01:33:24 EST 2009 x86_64 x86_64
Počet upozornění           1
Poprvé viděno               St 4. únor 2009, 07:17:26 CET
Naposledy viděno             St 4. únor 2009, 07:17:26 CET
Místní ID                   cdb84e6f-af20-4b5a-96b4-1f1afd851ef8
Čísla řádků              

Původní zprávy auditu      

node=viklef.ceplovi.cz type=AVC msg=audit(1233728246.595:73): avc:  denied  { sys_module } for  pid=7540 comm="arping" capability=16 scontext=system_u:system_r:netutils_t:s0-s0:c0.c1023 tcontext=system_u:system_r:netutils_t:s0-s0:c0.c1023 tclass=capability

node=viklef.ceplovi.cz type=SYSCALL msg=audit(1233728246.595:73): arch=c000003e syscall=16 success=no exit=-19 a0=3 a1=8933 a2=7fff8472d1a0 a3=7fff8472bcd0 items=0 ppid=7539 pid=7540 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="arping" exe="/sbin/arping" subj=system_u:system_r:netutils_t:s0-s0:c0.c1023 key=(null)

No, that is a different unrelated issue.

Allowing network utilities to load kernel modules.   That seems like a good idea?

 :^(