Userspace AVC auditing on policy load

Userspace AVC auditing on policy load

[Chris PeBenito]

I was looking into this dbus-broker audit message, which has the wrong audit type:

audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295 
subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice 
(seqno=2)

This is due to dbus-broker setting their avc log callback to send USER_AVC audit 
messages for everything that comes to the libselinux log callback. I think the 
right thing to do there is to change it to emit USER_SELINUX_ERR audit messages 
if the log message is SELINUX_ERROR, otherwise log the message using their 
regular method (stderr I think).

But the question became, why is the userspace AVC not simply emitting its own 
USER_MAC_POLICY_LOAD audit message instead of sending a message to the log callback?

-- 
Chris PeBenito

Re: Userspace AVC auditing on policy load

[Stephen Smalley]

On Wed, Aug 26, 2020 at 9:26 AM Chris PeBenito
<chpebeni@linux.microsoft.com> wrote:
>
> I was looking into this dbus-broker audit message, which has the wrong audit type:
>
> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295
> subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice
> (seqno=2)
>
> This is due to dbus-broker setting their avc log callback to send USER_AVC audit
> messages for everything that comes to the libselinux log callback. I think the
> right thing to do there is to change it to emit USER_SELINUX_ERR audit messages
> if the log message is SELINUX_ERROR, otherwise log the message using their
> regular method (stderr I think).
>
> But the question became, why is the userspace AVC not simply emitting its own
> USER_MAC_POLICY_LOAD audit message instead of sending a message to the log callback?

IIRC, the original userspace AVC support predates audit and the intent
was for the application to deal with dispatching messages as desired
from its callback, whether via libaudit or via syslog or whatever.
Not opposed to revisiting that but it would require some care, e.g.
not sure you'd want both libselinux and the application calling
audit_open().

Re: Userspace AVC auditing on policy load

[Chris PeBenito]

On 8/26/20 9:25 AM, Chris PeBenito wrote:
> I was looking into this dbus-broker audit message, which has the wrong audit type:
> 
> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295 
> subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice 
> (seqno=2)
> 
> This is due to dbus-broker setting their avc log callback to send USER_AVC audit 
> messages for everything that comes to the libselinux log callback. I think the 
> right thing to do there is to change it to emit USER_SELINUX_ERR audit messages 
> if the log message is SELINUX_ERROR, otherwise log the message using their 
> regular method (stderr I think).
> 
> But the question became, why is the userspace AVC not simply emitting its own 
> USER_MAC_POLICY_LOAD audit message instead of sending a message to the log 
> callback?

Ok, I missed that there is a SELINUX_AVC log type and that's how the userspace 
denial messages are sent out. How about adding SELINUX_POLICYLOAD and 
SELINUX_ENFORCE log types so that callers can emit appropriate audit messages?

-- 
Chris PeBenito

Re: Userspace AVC auditing on policy load

[Stephen Smalley]

On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
<chpebeni@linux.microsoft.com> wrote:
>
> On 8/26/20 9:25 AM, Chris PeBenito wrote:
> > I was looking into this dbus-broker audit message, which has the wrong audit type:
> >
> > audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295
> > subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice
> > (seqno=2)
> >
> > This is due to dbus-broker setting their avc log callback to send USER_AVC audit
> > messages for everything that comes to the libselinux log callback. I think the
> > right thing to do there is to change it to emit USER_SELINUX_ERR audit messages
> > if the log message is SELINUX_ERROR, otherwise log the message using their
> > regular method (stderr I think).
> >
> > But the question became, why is the userspace AVC not simply emitting its own
> > USER_MAC_POLICY_LOAD audit message instead of sending a message to the log
> > callback?
>
> Ok, I missed that there is a SELINUX_AVC log type and that's how the userspace
> denial messages are sent out. How about adding SELINUX_POLICYLOAD and
> SELINUX_ENFORCE log types so that callers can emit appropriate audit messages?

Do we need two different new types or just one?  Otherwise, I don't
have a problem with adding new ones as long as it doesn't break
existing applications.

Re: Userspace AVC auditing on policy load

[Chris PeBenito]

On 8/26/20 10:46 AM, Stephen Smalley wrote:
> On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
> <chpebeni@linux.microsoft.com> wrote:
>>
>> On 8/26/20 9:25 AM, Chris PeBenito wrote:
>>> I was looking into this dbus-broker audit message, which has the wrong audit type:
>>>
>>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice
>>> (seqno=2)
>>>
>>> This is due to dbus-broker setting their avc log callback to send USER_AVC audit
>>> messages for everything that comes to the libselinux log callback. I think the
>>> right thing to do there is to change it to emit USER_SELINUX_ERR audit messages
>>> if the log message is SELINUX_ERROR, otherwise log the message using their
>>> regular method (stderr I think).
>>>
>>> But the question became, why is the userspace AVC not simply emitting its own
>>> USER_MAC_POLICY_LOAD audit message instead of sending a message to the log
>>> callback?
>>
>> Ok, I missed that there is a SELINUX_AVC log type and that's how the userspace
>> denial messages are sent out. How about adding SELINUX_POLICYLOAD and
>> SELINUX_ENFORCE log types so that callers can emit appropriate audit messages?
> 
> Do we need two different new types or just one?  Otherwise, I don't
> have a problem with adding new ones as long as it doesn't break
> existing applications.

Perhaps just the policyload.  There is a USER_MAC_POLICY_LOAD audit type which 
made me think of adding the SELINUX_POLICYLOAD type to the logging callback. 
There is the log message after processing the setenforce, but there isn't 
currently a corresponding USER_MAC_STATUS audit message type.  It seems like it 
is justifiable to have a USER_MAC_STATUS audit message for consistency, but I'm 
not sure how much value it provides.

-- 
Chris PeBenito

Re: Userspace AVC auditing on policy load

[Chris PeBenito]

On 8/26/20 10:46 AM, Stephen Smalley wrote:
> On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
> <chpebeni@linux.microsoft.com> wrote:
>>
>> On 8/26/20 9:25 AM, Chris PeBenito wrote:
>>> I was looking into this dbus-broker audit message, which has the wrong audit type:
>>>
>>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice
>>> (seqno=2)
>>>
>>> This is due to dbus-broker setting their avc log callback to send USER_AVC audit
>>> messages for everything that comes to the libselinux log callback. I think the
>>> right thing to do there is to change it to emit USER_SELINUX_ERR audit messages
>>> if the log message is SELINUX_ERROR, otherwise log the message using their
>>> regular method (stderr I think).
>>>
>>> But the question became, why is the userspace AVC not simply emitting its own
>>> USER_MAC_POLICY_LOAD audit message instead of sending a message to the log
>>> callback?
>>
>> Ok, I missed that there is a SELINUX_AVC log type and that's how the userspace
>> denial messages are sent out. How about adding SELINUX_POLICYLOAD and
>> SELINUX_ENFORCE log types so that callers can emit appropriate audit messages?
> 
> Do we need two different new types or just one?  Otherwise, I don't
> have a problem with adding new ones as long as it doesn't break
> existing applications.

Regarding the risk of breaking existing applications, I did some checking on 
some userspace AVC users and what they do in their log callback:

* systemd only audits SELINUX_AVC and SELINUX_ERROR messages and ignores 
others(as Petr noted)
* xorg-server audits SELINUX_AVC correctly but audits SELINUX_INFO as 
USER_MAC_POLICY_LOAD and everything else it ignores the type and audits as 
AUDIT_USER_SELINUX_ERR
* dbus-broker ignores type and audits everything as USER_AVC
* dbus-service ignores type and audits everything as USER AVC
* pam: pam_rootok ignores type and audits everything as USER_AVC
* sepgsql custom AVC implementation (this was news to me)
* shadow-utils only audits SELINUX_AVC and SELINUX_ERROR messages and others go 
to syslog
* cronie: no callback set

That's all the ones I could think of.  Which ones am I missing?

-- 
Chris PeBenito

Re: Userspace AVC auditing on policy load

[Stephen Smalley]

On Wed, Aug 26, 2020 at 2:28 PM Chris PeBenito
<chpebeni@linux.microsoft.com> wrote:
>
> On 8/26/20 10:46 AM, Stephen Smalley wrote:
> > On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
> > <chpebeni@linux.microsoft.com> wrote:
> >>
> >> On 8/26/20 9:25 AM, Chris PeBenito wrote:
> >>> I was looking into this dbus-broker audit message, which has the wrong audit type:
> >>>
> >>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295
> >>> subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice
> >>> (seqno=2)
> >>>
> >>> This is due to dbus-broker setting their avc log callback to send USER_AVC audit
> >>> messages for everything that comes to the libselinux log callback. I think the
> >>> right thing to do there is to change it to emit USER_SELINUX_ERR audit messages
> >>> if the log message is SELINUX_ERROR, otherwise log the message using their
> >>> regular method (stderr I think).
> >>>
> >>> But the question became, why is the userspace AVC not simply emitting its own
> >>> USER_MAC_POLICY_LOAD audit message instead of sending a message to the log
> >>> callback?
> >>
> >> Ok, I missed that there is a SELINUX_AVC log type and that's how the userspace
> >> denial messages are sent out. How about adding SELINUX_POLICYLOAD and
> >> SELINUX_ENFORCE log types so that callers can emit appropriate audit messages?
> >
> > Do we need two different new types or just one?  Otherwise, I don't
> > have a problem with adding new ones as long as it doesn't break
> > existing applications.
>
> Regarding the risk of breaking existing applications, I did some checking on
> some userspace AVC users and what they do in their log callback:
>
> * systemd only audits SELINUX_AVC and SELINUX_ERROR messages and ignores
> others(as Petr noted)
> * xorg-server audits SELINUX_AVC correctly but audits SELINUX_INFO as
> USER_MAC_POLICY_LOAD and everything else it ignores the type and audits as
> AUDIT_USER_SELINUX_ERR
> * dbus-broker ignores type and audits everything as USER_AVC
> * dbus-service ignores type and audits everything as USER AVC
> * pam: pam_rootok ignores type and audits everything as USER_AVC
> * sepgsql custom AVC implementation (this was news to me)
> * shadow-utils only audits SELINUX_AVC and SELINUX_ERROR messages and others go
> to syslog
> * cronie: no callback set
>
> That's all the ones I could think of.  Which ones am I missing?

Short of searching for everything that calls avc_init() or
selinux_set_callback(), I don't know.  Android defines a common log
callback via https://android.googlesource.com/platform/external/selinux/+/refs/heads/master/libselinux/src/android/android.c#236
that funnels everything except for INFO and WARNING to its error stream.

Sounds like introducing new types will do no harm with the possible
exception of XSELinux and that's rarely used.
Certainly won't break anything.

Re: Userspace AVC auditing on policy load

[Dominick Grift]

Chris PeBenito <chpebeni@linux.microsoft.com> writes:

> On 8/26/20 10:46 AM, Stephen Smalley wrote:
>> On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
>> <chpebeni@linux.microsoft.com> wrote:
>>>
>>> On 8/26/20 9:25 AM, Chris PeBenito wrote:
>>>> I was looking into this dbus-broker audit message, which has the wrong audit type:
>>>>
>>>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295
>>>> subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice
>>>> (seqno=2)
>>>>
>>>> This is due to dbus-broker setting their avc log callback to send USER_AVC audit
>>>> messages for everything that comes to the libselinux log callback. I think the
>>>> right thing to do there is to change it to emit USER_SELINUX_ERR audit messages
>>>> if the log message is SELINUX_ERROR, otherwise log the message using their
>>>> regular method (stderr I think).
>>>>
>>>> But the question became, why is the userspace AVC not simply emitting its own
>>>> USER_MAC_POLICY_LOAD audit message instead of sending a message to the log
>>>> callback?
>>>
>>> Ok, I missed that there is a SELINUX_AVC log type and that's how the userspace
>>> denial messages are sent out. How about adding SELINUX_POLICYLOAD and
>>> SELINUX_ENFORCE log types so that callers can emit appropriate audit messages?
>> Do we need two different new types or just one?  Otherwise, I don't
>> have a problem with adding new ones as long as it doesn't break
>> existing applications.
>
> Regarding the risk of breaking existing applications, I did some
> checking on some userspace AVC users and what they do in their log
> callback:
>
> * systemd only audits SELINUX_AVC and SELINUX_ERROR messages and
>   ignores others(as Petr noted)
> * xorg-server audits SELINUX_AVC correctly but audits SELINUX_INFO as
>   USER_MAC_POLICY_LOAD and everything else it ignores the type and
>  audits as AUDIT_USER_SELINUX_ERR
> * dbus-broker ignores type and audits everything as USER_AVC
> * dbus-service ignores type and audits everything as USER AVC
> * pam: pam_rootok ignores type and audits everything as USER_AVC
> * sepgsql custom AVC implementation (this was news to me)
> * shadow-utils only audits SELINUX_AVC and SELINUX_ERROR messages and
>   others go to syslog
> * cronie: no callback set
>
> That's all the ones I could think of.  Which ones am I missing?

Probably libreswan, AFAIK that one might also still be using
avc_has_perm() instead of selinux_check_access().

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

Re: Userspace AVC auditing on policy load

[Chris PeBenito]

On 8/26/20 3:07 PM, Dominick Grift wrote:
> Chris PeBenito <chpebeni@linux.microsoft.com> writes:
> 
>> On 8/26/20 10:46 AM, Stephen Smalley wrote:
>>> On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
>>> <chpebeni@linux.microsoft.com> wrote:
>>>>
>>>> On 8/26/20 9:25 AM, Chris PeBenito wrote:
>>>>> I was looking into this dbus-broker audit message, which has the wrong audit type:
>>>>>
>>>>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295
>>>>> subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice
>>>>> (seqno=2)
>>>>>
>>>>> This is due to dbus-broker setting their avc log callback to send USER_AVC audit
>>>>> messages for everything that comes to the libselinux log callback. I think the
>>>>> right thing to do there is to change it to emit USER_SELINUX_ERR audit messages
>>>>> if the log message is SELINUX_ERROR, otherwise log the message using their
>>>>> regular method (stderr I think).
>>>>>
>>>>> But the question became, why is the userspace AVC not simply emitting its own
>>>>> USER_MAC_POLICY_LOAD audit message instead of sending a message to the log
>>>>> callback?
>>>>
>>>> Ok, I missed that there is a SELINUX_AVC log type and that's how the userspace
>>>> denial messages are sent out. How about adding SELINUX_POLICYLOAD and
>>>> SELINUX_ENFORCE log types so that callers can emit appropriate audit messages?
>>> Do we need two different new types or just one?  Otherwise, I don't
>>> have a problem with adding new ones as long as it doesn't break
>>> existing applications.
>>
>> Regarding the risk of breaking existing applications, I did some
>> checking on some userspace AVC users and what they do in their log
>> callback:
>>
>> * systemd only audits SELINUX_AVC and SELINUX_ERROR messages and
>>    ignores others(as Petr noted)
>> * xorg-server audits SELINUX_AVC correctly but audits SELINUX_INFO as
>>    USER_MAC_POLICY_LOAD and everything else it ignores the type and
>>   audits as AUDIT_USER_SELINUX_ERR
>> * dbus-broker ignores type and audits everything as USER_AVC
>> * dbus-service ignores type and audits everything as USER AVC
>> * pam: pam_rootok ignores type and audits everything as USER_AVC
>> * sepgsql custom AVC implementation (this was news to me)
>> * shadow-utils only audits SELINUX_AVC and SELINUX_ERROR messages and
>>    others go to syslog
>> * cronie: no callback set
>>
>> That's all the ones I could think of.  Which ones am I missing?
> 
> Probably libreswan, AFAIK that one might also still be using
> avc_has_perm() instead of selinux_check_access().

You're correct, it is still use avc_has_perm().  There is no log callback set here.

-- 
Chris PeBenito

Re: Userspace AVC auditing on policy load

[Dominick Grift]

Chris PeBenito <chpebeni@linux.microsoft.com> writes:

> On 8/26/20 3:07 PM, Dominick Grift wrote:
>> Chris PeBenito <chpebeni@linux.microsoft.com> writes:
>> 
>>> On 8/26/20 10:46 AM, Stephen Smalley wrote:
>>>> On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
>>>> <chpebeni@linux.microsoft.com> wrote:
>>>>>
>>>>> On 8/26/20 9:25 AM, Chris PeBenito wrote:
>>>>>> I was looking into this dbus-broker audit message, which has the wrong audit type:
>>>>>>
>>>>>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295
>>>>>> subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice
>>>>>> (seqno=2)
>>>>>>
>>>>>> This is due to dbus-broker setting their avc log callback to send USER_AVC audit
>>>>>> messages for everything that comes to the libselinux log callback. I think the
>>>>>> right thing to do there is to change it to emit USER_SELINUX_ERR audit messages
>>>>>> if the log message is SELINUX_ERROR, otherwise log the message using their
>>>>>> regular method (stderr I think).
>>>>>>
>>>>>> But the question became, why is the userspace AVC not simply emitting its own
>>>>>> USER_MAC_POLICY_LOAD audit message instead of sending a message to the log
>>>>>> callback?
>>>>>
>>>>> Ok, I missed that there is a SELINUX_AVC log type and that's how the userspace
>>>>> denial messages are sent out. How about adding SELINUX_POLICYLOAD and
>>>>> SELINUX_ENFORCE log types so that callers can emit appropriate audit messages?
>>>> Do we need two different new types or just one?  Otherwise, I don't
>>>> have a problem with adding new ones as long as it doesn't break
>>>> existing applications.
>>>
>>> Regarding the risk of breaking existing applications, I did some
>>> checking on some userspace AVC users and what they do in their log
>>> callback:
>>>
>>> * systemd only audits SELINUX_AVC and SELINUX_ERROR messages and
>>>    ignores others(as Petr noted)
>>> * xorg-server audits SELINUX_AVC correctly but audits SELINUX_INFO as
>>>    USER_MAC_POLICY_LOAD and everything else it ignores the type and
>>>   audits as AUDIT_USER_SELINUX_ERR
>>> * dbus-broker ignores type and audits everything as USER_AVC
>>> * dbus-service ignores type and audits everything as USER AVC
>>> * pam: pam_rootok ignores type and audits everything as USER_AVC
>>> * sepgsql custom AVC implementation (this was news to me)
>>> * shadow-utils only audits SELINUX_AVC and SELINUX_ERROR messages and
>>>    others go to syslog
>>> * cronie: no callback set
>>>
>>> That's all the ones I could think of.  Which ones am I missing?
>> Probably libreswan, AFAIK that one might also still be using
>> avc_has_perm() instead of selinux_check_access().
>
> You're correct, it is still use avc_has_perm().  There is no log callback set here.

glibc nscd (also seems to be still using avc_has_perm())

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

Re: Userspace AVC auditing on policy load

[Petr Lautrbach]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On Wed, Aug 26, 2020 at 09:25:18AM -0400, Chris PeBenito wrote:
> I was looking into this dbus-broker audit message, which has the wrong audit type:
> 
> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 ses=4294967295
> subj=system_u:system_r:system_dbusd_t msg='avc:  received policyload notice
> (seqno=2)
> 
> This is due to dbus-broker setting their avc log callback to send USER_AVC
> audit messages for everything that comes to the libselinux log callback. I
> think the right thing to do there is to change it to emit USER_SELINUX_ERR
> audit messages if the log message is SELINUX_ERROR, otherwise log the
> message using their regular method (stderr I think).

Similar problem existed in systemd. It was fixed by the following commit
https://github.com/systemd/systemd/commit/6227fc14c48c4c17daed4b91f61cdd4aa375790a
which lets systemd log callback to ignore everything but SELINUX_AVC and SELINUX_ERR

I believe this is the same problem which should be fixed in dbus and dbus-broker


> But the question became, why is the userspace AVC not simply emitting its
> own USER_MAC_POLICY_LOAD audit message instead of sending a message to the
> log callback?
> 
> -- 
> Chris PeBenito
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Userspace AVC auditing on policy load

[Richard Haines]

On Wed, 2020-08-26 at 15:15 -0400, Chris PeBenito wrote:
> On 8/26/20 3:07 PM, Dominick Grift wrote:
>> Chris PeBenito <chpebeni@linux.microsoft.com> writes:
>>

>>> On 8/26/20 10:46 AM, Stephen Smalley wrote:
>>>> On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
>>>> <chpebeni@linux.microsoft.com> wrote:
>>>>> On 8/26/20 9:25 AM, Chris PeBenito wrote:
>>>>>> I was looking into this dbus-broker audit message, which
>>>>>> has the wrong audit type:
>>>>>>

>>>>>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295
>>>>>> ses=4294967295
>>>>>> subj=system_u:system_r:system_dbusd_t msg='avc:  received
>>>>>> policyload notice
>>>>>> (seqno=2)
>>>>>>

>>>>>> This is due to dbus-broker setting their avc log callback
>>>>>> to send USER_AVC audit
>>>>>> messages for everything that comes to the libselinux log
>>>>>> callback. I think the
>>>>>> right thing to do there is to change it to emit
>>>>>> USER_SELINUX_ERR audit messages
>>>>>> if the log message is SELINUX_ERROR, otherwise log the
>>>>>> message using their
>>>>>> regular method (stderr I think).
>>>>>>

>>>>>> But the question became, why is the userspace AVC not
>>>>>> simply emitting its own
>>>>>> USER_MAC_POLICY_LOAD audit message instead of sending a
>>>>>> message to the log
>>>>>> callback?
>>>>>

>>>>> Ok, I missed that there is a SELINUX_AVC log type and that's
>>>>> how the userspace
>>>>> denial messages are sent out. How about adding
>>>>> SELINUX_POLICYLOAD and
>>>>> SELINUX_ENFORCE log types so that callers can emit
>>>>> appropriate audit messages?
>>>> Do we need two different new types or just one?  Otherwise, I
>>>> don't
>>>> have a problem with adding new ones as long as it doesn't break
>>>> existing applications.
>>>

>>> Regarding the risk of breaking existing applications, I did some
>>> checking on some userspace AVC users and what they do in their
>>> log
>>> callback:
>>>

>>> * systemd only audits SELINUX_AVC and SELINUX_ERROR messages and
>>>    ignores others(as Petr noted)
>>> * xorg-server audits SELINUX_AVC correctly but audits
>>> SELINUX_INFO as
>>>    USER_MAC_POLICY_LOAD and everything else it ignores the type
>>> and
>>>   audits as AUDIT_USER_SELINUX_ERR
>>> * dbus-broker ignores type and audits everything as USER_AVC
>>> * dbus-service ignores type and audits everything as USER AVC
>>> * pam: pam_rootok ignores type and audits everything as USER_AVC
>>> * sepgsql custom AVC implementation (this was news to me)
>>> * shadow-utils only audits SELINUX_AVC and SELINUX_ERROR messages
>>> and
>>>    others go to syslog
>>> * cronie: no callback set
>>>

>>> That's all the ones I could think of.  Which ones am I missing?
>>

>> Probably libreswan, AFAIK that one might also still be using
>> avc_has_perm() instead of selinux_check_access().
>

> You're correct, it is still use avc_has_perm().  There is no log
> callback set here.
>

ipsec-tools (racoon) is another. I did patches for this and LibreSwan a 
few years ago, they never went far:

ipsec-tools: 
https://marc.info/?l=ipsec-tools-devel&m=149441917501329&w=2
LibreSwan: 
https://lists.libreswan.org/pipermail/swan-dev/2017-May/001860.html

Re: Userspace AVC auditing on policy load

[Dominick Grift]

Richard Haines <richard_c_haines@btinternet.com> writes:

> On Wed, 2020-08-26 at 15:15 -0400, Chris PeBenito wrote:
>> On 8/26/20 3:07 PM, Dominick Grift wrote:
>>> Chris PeBenito <chpebeni@linux.microsoft.com> writes:
>>>
>
>>>> On 8/26/20 10:46 AM, Stephen Smalley wrote:
>>>>> On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
>>>>> <chpebeni@linux.microsoft.com> wrote:
>>>>>> On 8/26/20 9:25 AM, Chris PeBenito wrote:
>>>>>>> I was looking into this dbus-broker audit message, which
>>>>>>> has the wrong audit type:
>>>>>>>
>
>>>>>>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295
>>>>>>> ses=4294967295
>>>>>>> subj=system_u:system_r:system_dbusd_t msg='avc:  received
>>>>>>> policyload notice
>>>>>>> (seqno=2)
>>>>>>>
>
>>>>>>> This is due to dbus-broker setting their avc log callback
>>>>>>> to send USER_AVC audit
>>>>>>> messages for everything that comes to the libselinux log
>>>>>>> callback. I think the
>>>>>>> right thing to do there is to change it to emit
>>>>>>> USER_SELINUX_ERR audit messages
>>>>>>> if the log message is SELINUX_ERROR, otherwise log the
>>>>>>> message using their
>>>>>>> regular method (stderr I think).
>>>>>>>
>
>>>>>>> But the question became, why is the userspace AVC not
>>>>>>> simply emitting its own
>>>>>>> USER_MAC_POLICY_LOAD audit message instead of sending a
>>>>>>> message to the log
>>>>>>> callback?
>>>>>>
>
>>>>>> Ok, I missed that there is a SELINUX_AVC log type and that's
>>>>>> how the userspace
>>>>>> denial messages are sent out. How about adding
>>>>>> SELINUX_POLICYLOAD and
>>>>>> SELINUX_ENFORCE log types so that callers can emit
>>>>>> appropriate audit messages?
>>>>> Do we need two different new types or just one?  Otherwise, I
>>>>> don't
>>>>> have a problem with adding new ones as long as it doesn't break
>>>>> existing applications.
>>>>
>
>>>> Regarding the risk of breaking existing applications, I did some
>>>> checking on some userspace AVC users and what they do in their
>>>> log
>>>> callback:
>>>>
>
>>>> * systemd only audits SELINUX_AVC and SELINUX_ERROR messages and
>>>>    ignores others(as Petr noted)
>>>> * xorg-server audits SELINUX_AVC correctly but audits
>>>> SELINUX_INFO as
>>>>    USER_MAC_POLICY_LOAD and everything else it ignores the type
>>>> and
>>>>   audits as AUDIT_USER_SELINUX_ERR
>>>> * dbus-broker ignores type and audits everything as USER_AVC
>>>> * dbus-service ignores type and audits everything as USER AVC
>>>> * pam: pam_rootok ignores type and audits everything as USER_AVC
>>>> * sepgsql custom AVC implementation (this was news to me)
>>>> * shadow-utils only audits SELINUX_AVC and SELINUX_ERROR messages
>>>> and
>>>>    others go to syslog
>>>> * cronie: no callback set
>>>>
>
>>>> That's all the ones I could think of.  Which ones am I missing?
>>>
>
>>> Probably libreswan, AFAIK that one might also still be using
>>> avc_has_perm() instead of selinux_check_access().
>>
>
>> You're correct, it is still use avc_has_perm().  There is no log
>> callback set here.
>>
>
> ipsec-tools (racoon) is another. I did patches for this and LibreSwan
> a few years ago, they never went far:
>
> ipsec-tools:
> https://marc.info/?l=ipsec-tools-devel&m=149441917501329&w=2
> LibreSwan:
> https://lists.libreswan.org/pipermail/swan-dev/2017-May/001860.html
>
>

Looking at the libreswan thread, the situation changed significantly
since avc_has_perm() is just no longer supported AFAIK. So labeled-ipsec
is currently just broken. Also RHEL6 is EOL so that should not be an
issue.

Maybe it is possible to revive that thread?

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

Re: Userspace AVC auditing on policy load

[Dominick Grift]

Richard Haines <richard_c_haines@btinternet.com> writes:

> On Wed, 2020-08-26 at 15:15 -0400, Chris PeBenito wrote:
>> On 8/26/20 3:07 PM, Dominick Grift wrote:
>>> Chris PeBenito <chpebeni@linux.microsoft.com> writes:
>>>
>
>>>> On 8/26/20 10:46 AM, Stephen Smalley wrote:
>>>>> On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito
>>>>> <chpebeni@linux.microsoft.com> wrote:
>>>>>> On 8/26/20 9:25 AM, Chris PeBenito wrote:
>>>>>>> I was looking into this dbus-broker audit message, which
>>>>>>> has the wrong audit type:
>>>>>>>
>
>>>>>>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295
>>>>>>> ses=4294967295
>>>>>>> subj=system_u:system_r:system_dbusd_t msg='avc:  received
>>>>>>> policyload notice
>>>>>>> (seqno=2)
>>>>>>>
>
>>>>>>> This is due to dbus-broker setting their avc log callback
>>>>>>> to send USER_AVC audit
>>>>>>> messages for everything that comes to the libselinux log
>>>>>>> callback. I think the
>>>>>>> right thing to do there is to change it to emit
>>>>>>> USER_SELINUX_ERR audit messages
>>>>>>> if the log message is SELINUX_ERROR, otherwise log the
>>>>>>> message using their
>>>>>>> regular method (stderr I think).
>>>>>>>
>
>>>>>>> But the question became, why is the userspace AVC not
>>>>>>> simply emitting its own
>>>>>>> USER_MAC_POLICY_LOAD audit message instead of sending a
>>>>>>> message to the log
>>>>>>> callback?
>>>>>>
>
>>>>>> Ok, I missed that there is a SELINUX_AVC log type and that's
>>>>>> how the userspace
>>>>>> denial messages are sent out. How about adding
>>>>>> SELINUX_POLICYLOAD and
>>>>>> SELINUX_ENFORCE log types so that callers can emit
>>>>>> appropriate audit messages?
>>>>> Do we need two different new types or just one?  Otherwise, I
>>>>> don't
>>>>> have a problem with adding new ones as long as it doesn't break
>>>>> existing applications.
>>>>
>
>>>> Regarding the risk of breaking existing applications, I did some
>>>> checking on some userspace AVC users and what they do in their
>>>> log
>>>> callback:
>>>>
>
>>>> * systemd only audits SELINUX_AVC and SELINUX_ERROR messages and
>>>>    ignores others(as Petr noted)
>>>> * xorg-server audits SELINUX_AVC correctly but audits
>>>> SELINUX_INFO as
>>>>    USER_MAC_POLICY_LOAD and everything else it ignores the type
>>>> and
>>>>   audits as AUDIT_USER_SELINUX_ERR
>>>> * dbus-broker ignores type and audits everything as USER_AVC
>>>> * dbus-service ignores type and audits everything as USER AVC
>>>> * pam: pam_rootok ignores type and audits everything as USER_AVC
>>>> * sepgsql custom AVC implementation (this was news to me)
>>>> * shadow-utils only audits SELINUX_AVC and SELINUX_ERROR messages
>>>> and
>>>>    others go to syslog
>>>> * cronie: no callback set
>>>>
>
>>>> That's all the ones I could think of.  Which ones am I missing?
>>>
>
>>> Probably libreswan, AFAIK that one might also still be using
>>> avc_has_perm() instead of selinux_check_access().
>>
>
>> You're correct, it is still use avc_has_perm().  There is no log
>> callback set here.
>>
>
> ipsec-tools (racoon) is another. I did patches for this and LibreSwan
> a few years ago, they never went far:
>
> ipsec-tools:
> https://marc.info/?l=ipsec-tools-devel&m=149441917501329&w=2
> LibreSwan:
> https://lists.libreswan.org/pipermail/swan-dev/2017-May/001860.html
>
>

I visited #swan and reminded the maintainers of the libreswan patch,
they are going to address your patch.

ipsec-tools is dead and have CVE's and so not sure if there is any point
to that.

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift