Hi, With dbus 1.10.2 (on Debian), when I'm running "semodule -B", the system dbus daemon is complaining with the following message: nov 03 15:02:57 soldur dbus[1057]: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=3) exe="/usr/bin/dbus-daemon" sauid=102 hostname=? addr=? terminal=? This is the system dbus daemon running as "messagebus": message+ 1057 0.0 0.0 127756 4524 ? Ssl 10:39 0:11 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation Looking at the capabilities: $ sudo getpcaps 1057 Capabilities for `1057': = cap_audit_write+ep All other user_avc seems to be properly logged in audit. An idea?

On Tuesday, November 03, 2015 05:05:55 PM Laurent Bigonville wrote: > Hi, > > With dbus 1.10.2 (on Debian), when I'm running "semodule -B", the system > dbus daemon is complaining with the following message: > > nov 03 15:02:57 soldur dbus[1057]: Can't send to audit system: USER_AVC > avc: received policyload notice (seqno=3) exe="/usr/bin/dbus-daemon" > sauid=102 hostname=? addr=? terminal=? > > This is the system dbus daemon running as "messagebus": > > message+ 1057 0.0 0.0 127756 4524 ? Ssl 10:39 0:11 > /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile > --systemd-activation > > Looking at the capabilities: > > $ sudo getpcaps 1057 > Capabilities for `1057': = cap_audit_write+ep > > All other user_avc seems to be properly logged in audit. > > An idea? I'd patch it to syslog errno and other information to locate the syscall that's failing. Did socket fail? Did the send fail? Does it work in permissive mode?

On Tuesday, November 03, 2015 06:12:07 PM Laurent Bigonville wrote: > Le 03/11/15 17:28, Steve Grubb a écrit : > > On Tuesday, November 03, 2015 05:05:55 PM Laurent Bigonville wrote: > >> Hi, > >> > >> With dbus 1.10.2 (on Debian), when I'm running "semodule -B", the system > >> dbus daemon is complaining with the following message: > >> > >> nov 03 15:02:57 soldur dbus[1057]: Can't send to audit system: USER_AVC > >> avc: received policyload notice (seqno=3) exe="/usr/bin/dbus-daemon" > >> sauid=102 hostname=? addr=? terminal=? > >> > >> This is the system dbus daemon running as "messagebus": > >> > >> message+ 1057 0.0 0.0 127756 4524 ? Ssl 10:39 0:11 > >> /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile > >> --systemd-activation > >> > >> Looking at the capabilities: > >> > >> $ sudo getpcaps 1057 > >> Capabilities for `1057': = cap_audit_write+ep > >> > >> All other user_avc seems to be properly logged in audit. > >> > >> An idea? > > > > I'd patch it to syslog errno and other information to locate the syscall > > that's failing. Did socket fail? Did the send fail? Does it work in > > permissive mode? > > I'm running in permissive mode. > > I'm seeing a netlink open to the audit: > > dbus-daem 1057 messagebus 7u netlink 0t0 15248 AUDIT > > Apparently audit_send() returns -1 Since its -1, that would be an EPERM. No idea where this is coming from if you have CAP_AUDIT_WRITE. I use pscap to check that.

> I've been to reproduce this on F23 as well. I have not played around with that yet.

> BTW if I'm trying to compile audit with gcc optimization disabled (-O0) > I get: > > libtool: link: gcc -D_GNU_SOURCE -g -O0 -fstack-protector-strong > -Wformat -Werror=format-security -Wl,-z -Wl,relro -Wl,--as-needed -o > .libs/auvirt auvirt.o auvirt-list.o ausearch-time.o -L../../auparse > /<<PKGBUILDDIR>>/debian/build/auparse/.libs/libauparse.so > auvirt.o: In function `process_machine_id_event': > /<<PKGBUILDDIR>>/debian/build/tools/auvirt/../../../../tools/auvirt/auvirt.c > :484: undefined reference to `copy_str' Thanks. I see a similar report with a patch from yoctoproject.org whatever that is. I don't recall seeing the patch sent here. They list it as a C99 compiler change in semantics for inline functions. I have fixed this differently in the upstream code as commit #1132

https://fedorahosted.org/audit/changeset/1132 Thanks, -Steve

Le 03/11/15 21:08, Richard Guy Briggs a écrit : > On 15/11/03, Steve Grubb wrote: >> On Tuesday, November 03, 2015 06:12:07 PM Laurent Bigonville wrote: >>> I'm running in permissive mode. >>> >>> I'm seeing a netlink open to the audit: >>> >>> dbus-daem 1057 messagebus 7u netlink 0t0 15248 AUDIT >>> >>> Apparently audit_send() returns -1 >> >> Since its -1, that would be an EPERM. No idea where this is coming from >> if you have CAP_AUDIT_WRITE. I use pscap to check that. > > Are you in a container of any kind or any non-init USER namespace? I > can't see it being denied otherwise assuming it is only trying to send > AUDIT_USER_* class messages. (This assumes upstream kernel.) No, I initially saw this on my laptop and then tested on F23 in kvm.

> I guess I have to ask which kernel too, since changes to NET and PID > namespaces are somewhat recent and Debian tends on the side of > conservative to be stable. I'm under debian unstable and the kernel I'm running is 4.2 >>> I've been to reproduce this on F23 as well. >> >> I have not played around with that yet. > > What kernel is that? 4.2 too apparently. Cheers, Laurent Bigonville -- Linux-audit mailing list Linux-audit(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit

Le 05/11/15 04:23, Steve Grubb a écrit : > I tested this on Fedora 22 and did not get a USER_AVC from dbus, but > I also > did not get an error message in syslog. So, I don't know what to make > of it. > (And for the record, I have a bz open saying that USER_AVC is the > wrong event > type. They are blaming libselinux but I blame them for not using > AUDIT_USER_MAC_POLICY_LOAD.) The audit code in dbus has been refactored a bit in the version present F23 and debian unstable, so it might be related to this that. Do you still have the number of that bz bug?

Le 05/11/15 04:23, Steve Grubb a écrit : > On Tuesday, November 03, 2015 09:48:31 PM Laurent Bigonville wrote: >> Le 03/11/15 21:08, Richard Guy Briggs a écrit : >>> On 15/11/03, Steve Grubb wrote: >>>> On Tuesday, November 03, 2015 06:12:07 PM Laurent Bigonville wrote: >>>>> I'm running in permissive mode. >>>>> >>>>> I'm seeing a netlink open to the audit: >>>>> >>>>> dbus-daem 1057 messagebus 7u netlink 0t0 15248 AUDIT >>>>> >>>>> Apparently audit_send() returns -1 >>>> >>>> Since its -1, that would be an EPERM. No idea where this is coming from >>>> if you have CAP_AUDIT_WRITE. I use pscap to check that. >>> >>> Are you in a container of any kind or any non-init USER namespace? I >>> can't see it being denied otherwise assuming it is only trying to send >>> AUDIT_USER_* class messages. (This assumes upstream kernel.) >> >> No, I initially saw this on my laptop and then tested on F23 in kvm. > > I tested this on Fedora 22 and did not get a USER_AVC from dbus, but I > also > did not get an error message in syslog. So, I don't know what to make of > it. (And for the record, I have a bz open saying that USER_AVC is the > wrong event type. They are blaming libselinux but I blame them for not > using > AUDIT_USER_MAC_POLICY_LOAD.) The audit code in dbus has been refactored a bit in the version present F23 and debian unstable, so it might be related to this that.

Le 06/11/15 00:03, Steve Grubb a écrit : > On Thursday, November 05, 2015 09:32:09 AM Laurent Bigonville wrote: >> >> Le 05/11/15 04:23, Steve Grubb a écrit : >>> >>> On Tuesday, November 03, 2015 09:48:31 PM Laurent Bigonville wrote: >>>> >>>> Le 03/11/15 21:08, Richard Guy Briggs a écrit : >>>>> >>>>> On 15/11/03, Steve Grubb wrote: >>>>>> >>>>>> On Tuesday, November 03, 2015 06:12:07 PM Laurent Bigonville wrote: >>>>>>> >>>>>>> I'm running in permissive mode. >>>>>>> >>>>>>> I'm seeing a netlink open to the audit: >>>>>>> >>>>>>> dbus-daem 1057 messagebus 7u netlink 0t0 15248 AUDIT >>>>>>> >>>>>>> Apparently audit_send() returns -1 >>>>>> >>>>>> Since its -1, that would be an EPERM. No idea where this is coming >>>>>> from >>>>>> if you have CAP_AUDIT_WRITE. I use pscap to check that. >>>>> >>>>> Are you in a container of any kind or any non-init USER namespace? I >>>>> can't see it being denied otherwise assuming it is only trying to send >>>>> AUDIT_USER_* class messages. (This assumes upstream kernel.) >>>> >>>> No, I initially saw this on my laptop and then tested on F23 in kvm. >>> >>> I tested this on Fedora 22 and did not get a USER_AVC from dbus, but I >>> also >>> did not get an error message in syslog. So, I don't know what to make of >>> it. (And for the record, I have a bz open saying that USER_AVC is the >>> wrong event type. They are blaming libselinux but I blame them for not >>> using >>> AUDIT_USER_MAC_POLICY_LOAD.) >> >> The audit code in dbus has been refactored a bit in the version present >> F23 and debian unstable, so it might be related to this that. > > > I filed a bz to get this fixed: > https://bugzilla.redhat.com/show_bug.cgi?id=1278602 > > The root cause is listed in the bug. Dbus has 2 threads, one with > CAP_AUDIT_WRITE and one without. The one without is the one trying to send > the > event. Thanks, I've opened a bug upstream too: https://bugs.freedesktop.org/show_bug.cgi?id=92832 -- Linux-audit mailing list Linux-audit(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit