All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Bigonville <bigon@debian.org>
To: linux-audit@redhat.com
Subject: Re: SELinux policy reload cannot be sent to audit system
Date: Fri, 6 Nov 2015 00:19:17 +0100	[thread overview]
Message-ID: <563BE3F5.6030808@debian.org> (raw)
In-Reply-To: <4121374.MmbOH8Er09@x2>

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

  reply	other threads:[~2015-11-05 23:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03 16:05 SELinux policy reload cannot be sent to audit system Laurent Bigonville
2015-11-03 16:28 ` Steve Grubb
2015-11-03 16:38   ` Paul Moore
2015-11-03 17:12   ` Laurent Bigonville
2015-11-03 19:33     ` Steve Grubb
2015-11-03 20:08       ` Richard Guy Briggs
2015-11-03 20:48         ` Laurent Bigonville
2015-11-05  3:23           ` Steve Grubb
2015-11-05  8:32             ` Laurent Bigonville
2015-11-05  9:26               ` Laurent Bigonville
2015-11-05 13:20                 ` Steve Grubb
2015-11-05 23:03               ` Steve Grubb
2015-11-05 23:19                 ` Laurent Bigonville [this message]
2015-11-06  1:25                   ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=563BE3F5.6030808@debian.org \
    --to=bigon@debian.org \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.