While chasing some other interesting things, I needed to use tcpdump. This resulted in a minor avc denial: Jan 8 01:11:06 testbed kernel: [26965.229255] audit: type=1400 audit(1420701066.037:1257): avc: denied { search } for pid=5953 comm="tcpdump" name="/" dev="debugfs" ino=1 ipaddr=173.173.113.156 scontext=root:sysadm_r:netutils_t tcontext=system_u:object_r:debugfs_t tclass=dir permissive=1 Thankfully there's an interface that covers this: kernel_search_debugfs() This looks relatively benign and easy to fix/dontaudit. I'm somewhat inclined in the direction of dontaudit / upstream reporting, because at first blush I would say tcpdump has no business looking through /sys/kernel/debug (the only thing I have as debugfs_t). Further, this only shows up if I am nonspecific as to the interface I am sniffing which makes me think there's some sort of function internal to tcpdump that does a 'search' for interfaces it can use which passes over that debugfs location.
Is there a particular tcpdump command that you were doing? I tried here but a "standard" tcpdump -i <iface> does not give that denial here.
I missed your "if I am nonspecific" paragraph. Another denial I get then is: time->Sun Jun 7 10:52:50 2015 type=AVC msg=audit(1433667170.527:83): avc: denied { read } for pid=17708 comm="tcpdump" name="usbmon4" dev="devtmpfs" ino=163 scontext=staff_u:sysadm_r:netutils_t:s0 tcontext=system_u:object_r:usbmon_device_t:s0 tclass=chr_file permissive=0 I'm going to dontaudit both of these for now
Another set of permissions coming up (now on unstable) due to capabilities being used: 22: kernel_request_load_module(netutils_t) # request nfnetlink-subsys-3 (queue) 23: allow netutils_t self:process getcap; # check capabilities 24: allow netutils_t self:capability setpcap; # set capability
Committed to our repo, will be part of r7
r7 is now ~arch
r7 is stable
