SELinux policy reload cannot be sent to audit system

DISCUSSION Laurent Bigonville 4 participants 14 messages Nov 3, 2015 – Nov 6, 2015

Share & tools

Laurent Bigonville

author

2015-11-03 16:06 UTC #0 lore raw

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?

Cheers,

Laurent Bigonville

Steve Grubb

2015-11-03 16:28 UTC #1 lore raw

Quoted 15 lines · Laurent Bigonville

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

Quoted 8 lines

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?

-Steve

Paul Moore

2015-11-03 16:38 UTC #2 lore raw

Quoted 21 lines · Steve Grubb

Quoted 20 lines · Laurent Bigonville
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

Quoted 7 lines

Quoted 3 lines
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 would also verify that your loaded SELinux policy is not blocking the CAP_AUDIT_WRITE capability or the netlink_audit_socket:nlmsg_relay permission.

Signature · 2 lines

paul moore
www.paul-moore.com

Laurent Bigonville

author

2015-11-03 17:12 UTC #3 lore raw

In reply to Steve Grubb

Quoted 21 lines · Steve Grubb

Quoted 20 lines · Laurent Bigonville
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

Quoted 6 lines

Quoted 3 lines
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

I've been to reproduce this on F23 as well.

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'

Cheers,

Laurent Bigonville

Steve Grubb

2015-11-03 19:33 UTC #4 lore raw

Quoted 30 lines · Laurent Bigonville

Quoted 21 lines · Steve Grubb
Quoted 20 lines · Laurent Bigonville
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
Quoted 7 lines
Quoted 3 lines
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?

Quoted 7 lines

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.

Quoted 1 line

I've been to reproduce this on F23 as well.

I have not played around with that yet.

Quoted 10 lines

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

Richard Guy Briggs

2015-11-03 20:08 UTC #5 lore raw

Quoted 33 lines · Steve Grubb

Quoted 32 lines · Laurent Bigonville
Quoted 21 lines · Steve Grubb
Quoted 20 lines · Laurent Bigonville
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
Quoted 7 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 5 lines
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.)

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.

Quoted 3 lines

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

What kernel is that?

Quoted 11 lines

Quoted 10 lines
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'

Quoted 4 lines

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

Yocto is a framework for developing distributions for embedded devices.

Quoted 4 lines

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

- RGB

--
Richard Guy Briggs <[email protected]>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

Laurent Bigonville

author

2015-11-03 20:48 UTC #6 lore raw

Quoted 7 lines · Richard Guy Briggs

Quoted 6 lines · Steve Grubb
Quoted 5 lines · Laurent Bigonville
I'm running in permissive mode.
I'm seeing a netlink open to the audit:

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
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.

Quoted 3 lines

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

Quoted 4 lines

Quoted 3 lines
Quoted 2 lines
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

Steve Grubb

2015-11-05 03:23 UTC #7 lore raw

Quoted 11 lines · Laurent Bigonville

Quoted 10 lines · Richard Guy Briggs
Quoted 9 lines · Steve Grubb
Quoted 7 lines · Laurent Bigonville
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

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
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.)

-Steve

Quoted 22 lines

Quoted 3 lines
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
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Laurent Bigonville

author

2015-11-05 08:32 UTC #8 lore raw

Quoted 16 lines · Steve Grubb

Quoted 15 lines · Laurent Bigonville
Quoted 14 lines · Richard Guy Briggs
Quoted 10 lines · Steve Grubb
Quoted 7 lines · Laurent Bigonville
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.)

Quoted 6 lines

Quoted 1 line
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.

Do you still have the number of that bz bug?

Cheers,

Laurent Bigonville

author

2015-11-05 09:26 UTC #9 lore raw

Quoted 9 lines · Laurent Bigonville

Quoted 5 lines · Steve Grubb
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?

BTW, systemd is also apparently sending a USER_AVC event when the policy is reloaded.

Steve Grubb

2015-11-05 13:20 UTC #10 lore raw

Quoted 9 lines · Laurent Bigonville

Quoted 8 lines · Laurent Bigonville
Quoted 6 lines · Steve Grubb
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.)

Quoted 7 lines

Quoted 4 lines
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?
BTW, systemd is also apparently sending a USER_AVC event when the policy is reloaded.

This is bz 1195330.

-Steve

Steve Grubb

2015-11-05 23:03 UTC #11 lore raw

In reply to Laurent Bigonville

Quoted 30 lines · Laurent Bigonville

Quoted 21 lines · Steve Grubb
Quoted 11 lines · Laurent Bigonville
Quoted 10 lines · Richard Guy Briggs
Quoted 9 lines · Steve Grubb
Quoted 7 lines · Laurent Bigonville
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
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
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.)

Quoted 2 lines

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.

-Steve

Laurent Bigonville

author

2015-11-05 23:19 UTC #12 lore raw

Quoted 29 lines · Steve Grubb

Quoted 25 lines · Laurent Bigonville
Quoted 16 lines · Steve Grubb
Quoted 15 lines · Laurent Bigonville
Quoted 14 lines · Richard Guy Briggs
Quoted 10 lines · Steve Grubb
Quoted 7 lines · Laurent Bigonville
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.)
Quoted 8 lines
Quoted 1 line
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.)
Quoted 2 lines
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.

Quoted 6 lines

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

Paul Moore

2015-11-06 01:25 UTC #13 lore raw

Thanks guys, it looks like you found the root cause. It was on my todo list to play with this on Rawhide but I wanted to get through Richard's patches first.

Quoted 62 lines · Laurent Bigonville

Quoted 42 lines · Steve Grubb
Quoted 37 lines · Laurent Bigonville
Quoted 27 lines · Steve Grubb
Quoted 19 lines · Laurent Bigonville
Quoted 17 lines · Richard Guy Briggs
Quoted 14 lines · Steve Grubb
Quoted 8 lines · Laurent Bigonville
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 7 lines
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.)
Quoted 2 lines
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.
Quoted 7 lines
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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Signature · 7 lines

paul moore
www.paul-moore.com

--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit