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@xxxxxxxxxxxxxx>
National Security Agency
