kernel file handle leak?

Stephen Smalley sds at epoch.ncsc.mil
Tue Aug 17 11:27:20 UTC 2004


On Mon, 2004-08-16 at 21:55, Russell Coker wrote:
> When I boot a laptop with a Cardbus Ethernet card installed I get the 
> following avc messages related to a kernel file handle.  Is this a known 
> issue?
> 
> (1092707493.572:0): avc:  denied  { read write } for  pid=2131 exe=/sbin/ip 
> path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t 
> tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket
> audit(1092707493.581:0): avc:  denied  { read write } for  pid=2133 
> exe=/sbin/iwconfig path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707493.591:0): avc:  denied  { read write } for  pid=2135 
> exe=/sbin/ethtool path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707493.604:0): avc:  denied  { read write } for  pid=2139 
> exe=/sbin/modprobe path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:insmod_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707493.634:0): avc:  denied  { read write } for  pid=2141 
> exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707493.641:0): avc:  denied  { read write } for  pid=2143 
> exe=/sbin/dhclient path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707498.179:0): avc:  denied  { read write } for  pid=2316 
> exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707498.188:0): avc:  denied  { read write } for  pid=2318 
> exe=/sbin/ethtool path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707498.195:0): avc:  denied  { read write } for  pid=2320 
> exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707498.265:0): avc:  denied  { read write } for  pid=2331 
> exe=/sbin/ifconfig path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707499.315:0): avc:  denied  { read write } for  pid=2402 
> exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket
> audit(1092707499.369:0): avc:  denied  { read write } for  pid=2409 
> exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 
> scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t 
> tclass=unix_dgram_socket

I've seen udev leaking a descriptor to a Unix datagram socket to its
helper programs, but that is usually labeled udev_t (but would be
kernel_t if you didn't install the udev policy or label udev properly,
so that kernel_t failed to transition to udev_t when running udev).

I've also seen the kernel leaking descriptors to rootfs entries unpacked
from the initramfs to all processes; SELinux stomps on those and resets
them to the null device.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency




More information about the fedora-selinux-list mailing list