On Tue, Sep 12, 2017 at 05:57:53PM -0400, Paul Moore wrote:
> On Tue, Sep 12, 2017 at 3:31 PM, Dominick Grift <dac.override@xxxxxxxxx> 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 <dac.override@xxxxxxxxx> wrote:
> >> > On Tue, Sep 12, 2017 at 12:01:35PM -0400, Stephen Smalley wrote:
> >> >> On Sep 12, 2017 7:01 AM, "Dominick Grift" <dac.override@xxxxxxxxx> 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.
Works great. its now unix_dgram_socket
got this awesome procedure to test this stuff
1. create (non-legacy rawhide) bootable image from dssp2-standard source tree with `mkosi`
2. install copr and enable copr
3. update kernel
4. create new efi image with dracut
5. boot and do tests
recorded the whole procedure:
https://www.youtube.com/watch?v=ObuBJ9qucuY
>
> If it helps, v4.14 should be pretty quiet, no major changes like the
> past few releases.
>
> --
> paul moore
> www.paul-moore.com
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
Attachment:
signature.asc
Description: PGP signature
