On Tue, Sep 12, 2017 at 3:31 PM, Dominick Grift <[email protected]> wrote: > On Tue, Sep 12, 2017 at 02:55:38PM -0400, Paul Moore wrote: >> On Tue, Sep 12, 2017 at 1:36 PM, Dominick Grift <[email protected]> >> wrote: >> > On Tue, Sep 12, 2017 at 12:01:35PM -0400, Stephen Smalley wrote: >> >> On Sep 12, 2017 7:01 AM, "Dominick Grift" <[email protected]> wrote: >> >> >> >> I have extended socket class polcap enabled but i am still seeing "socket" >> >> class events and i was wondering whether that is to be expected? >> >> >> >> avc: denied { create } for pid=10484 comm="nethogs" scontext=wheel.id: >> >> sysadm.role:nethogs.subj:s0 tcontext=wheel.id:sysadm.role:nethogs.subj:s0 >> >> tclass=socket permissive=0 >> >> >> >> This seems to be common to processes that also create (and map! [1]) >> >> "packet_socket" sockets (tcpdump/nethogs) >> >> >> >> [1] avc: denied { map } for pid=10525 comm="nethogs" >> >> path="socket:[56040]" dev="sockfs" ino=56040 >> >> scontext=wheel.id:sysadm.role:nethogs.subj:s0 >> >> tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=packet_socket >> >> permissive=0 >> >> >> >> >> >> No, that is not expected. Can you enable sys call audit and get those >> >> records? >> > >> > type=PROCTITLE msg=audit(09/12/2017 19:35:54.063:4458) : proctitle=nethogs >> > enp8s0 >> > type=SYSCALL msg=audit(09/12/2017 19:35:54.063:4458) : arch=x86_64 >> > syscall=socket success=yes exit=5 a0=local a1=SOCK_RAW a2=ip a3=0xb4 >> > items=0 ppid=3251 pid=8963 auid=kcinimod uid=root gid=root euid=root >> > suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts5 ses=1 >> > comm=nethogs exe=/usr/sbin/nethogs >> > subj=wheel.id:sysadm.role:nethogs.subj:s0 key=(null) >> > type=AVC msg=audit(09/12/2017 19:35:54.063:4458) : avc: denied { create >> > } for pid=8963 comm=nethogs scontext=wheel.id:sysadm.role:nethogs.subj:s0 >> > tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=socket permissive=1 >> >> Ah ha, AF_UNIX/SOCK_RAW, that's the problem. Luis Ressel fixed this >> (see the commit below) and it should make it up to Linus during the >> current merge window (eventually, maybe, hopefully). >> >> If you run Fedora Rawhide, you can try one of recent kernel builds in >> the COPR repo below, it should have the fix. >> >> * https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext > > Thanks i will probably try this out in a virtual machine tomorrow (kind of > relieved now with a "stable" 4.13 on my bare bones after quite a turbulent > 4.12 and 4.13)
Okay, let me know how it works for you. If it helps, v4.14 should be pretty quiet, no major changes like the past few releases. -- paul moore www.paul-moore.com
