search

linux-audit / audit-kernel

GitHub mirror of the Linux Kernel's audit repository
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
Other
140 stars 37 forks source link

Q: should ANOM_PROMISCUOUS be accompanied or autonomous? #45

Closed rgbriggs closed 6 years ago

rgbriggs commented 7 years ago

The ANOM_PROMISCUOUS record is declared with context included, attaching itself to a SYSCALL record, but it already includes some subject attributes.

Should this be an autonomous record or should it be accompanying a SYSCALL record?

Recommend either removing the subject attributes from the ANOM_PROMISCUOUS, or (preferably) making them more complete and not adding a context reference to the audit_log... call.

type=SYSCALL msg=audit(05/12/2017 19:11:13.254:109) : arch=x86_64 syscall=ioctl success=yes exit=0 a0=0x17 a1=SIOCBRADDIF a2=0x7fdb72d74ad0 a3=0x2 items=0 ppid=1 pid=2284 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=libvirtd exe=/usr/sbin/libvirtd subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null)
type=ANOM_PROMISCUOUS msg=audit(05/12/2017 19:11:13.254:109) : dev=virbr0-nic prom=yes old_prom=no auid=unset uid=root gid=root ses=unset

note: net/core/dev.c:__dev_set_promiscuity()

pcmoore commented 7 years ago

Is it possible to change the interface promiscuity without a syscall? I know that the interface can change promiscuity indirectly (I believe bridging and/or some other interface layering can have that effect), but all of those configuration changes should be attached to a syscall, yes?

rgbriggs commented 7 years ago

As far as I know, promiscuity will drop when device link goes down, independent of userspace directives. Regardless, I think there is a more general problem that we want records to be tied to syscalls when they exist, but still want a record when it is a kernel thread and still need enough information to figure that out, particularly when it is a system configuration change.

pcmoore commented 6 years ago

In my opinion the proper behavior would be to tie the record with the associated SYSCALL record whenever possible.

rgbriggs commented 6 years ago

So given the situation, nothing should be changed, since it is already associated with a syscall due to using the current->audit_context and fields can't be changed other than to append, leaving auid, uid, gid and ses duplicating those in the syscall record.