systemd and dontaudit

systemd and dontaudit

[Russell Coker]

kernel_dontaudit_getattr_proc(systemd_logind_t)

The above hides the fact that systemd-logind wants to statfs /proc and that 
can cause it to abort in some situations, to refuse to respond to dbus 
requests, and to delay all logins by 25 seconds.

https://github.com/SELinuxProject/refpolicy/pull/995

I fixed it in this PR, but I think that perhaps we should allow all systemd 
processes to statfs /proc to avoid future problems.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: systemd and dontaudit

[Chris PeBenito]

On 7/22/2025 8:15 PM, Russell Coker wrote:
> kernel_dontaudit_getattr_proc(systemd_logind_t)
> 
> The above hides the fact that systemd-logind wants to statfs /proc and that
> can cause it to abort in some situations, to refuse to respond to dbus
> requests, and to delay all logins by 25 seconds.

Can you elaborate on what one of those failing situations is?


> https://github.com/SELinuxProject/refpolicy/pull/995
> 
> I fixed it in this PR, but I think that perhaps we should allow all systemd
> processes to statfs /proc to avoid future problems.

I'd be fine with this, especially since it's not an overly concerning 
access.


-- 
Chris PeBenito

Re: systemd and dontaudit

[Russell Coker]

On Wednesday, 23 July 2025 22:37:09 AEST Chris PeBenito wrote:
> On 7/22/2025 8:15 PM, Russell Coker wrote:
> > kernel_dontaudit_getattr_proc(systemd_logind_t)
> > 
> > The above hides the fact that systemd-logind wants to statfs /proc and
> > that
> > can cause it to abort in some situations, to refuse to respond to dbus
> > requests, and to delay all logins by 25 seconds.
> 
> Can you elaborate on what one of those failing situations is?

It only happened repeatedly on one of my systems.  I think that triggering 
that particular condition required multiple settings, so just not allowing 
statfs isn't necessarily enough, some other combination of things allowed and 
denied seemed necessary to get it into that state. The one system that had 
this had it persist across reboots but other systems never had it.  I had seen 
it briefly happen on other systems but a reboot fixed it.

I didn't put as much effort into investigating this as I might have because 
the access in question is fairly innocuous.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: systemd and dontaudit

[Dominick Grift]

Russell Coker <russell@coker.com.au> writes:

> On Wednesday, 23 July 2025 22:37:09 AEST Chris PeBenito wrote:
>> On 7/22/2025 8:15 PM, Russell Coker wrote:
>> > kernel_dontaudit_getattr_proc(systemd_logind_t)
>> > 
>> > The above hides the fact that systemd-logind wants to statfs /proc and
>> > that
>> > can cause it to abort in some situations, to refuse to respond to dbus
>> > requests, and to delay all logins by 25 seconds.
>> 
>> Can you elaborate on what one of those failing situations is?
>
> It only happened repeatedly on one of my systems.  I think that triggering 
> that particular condition required multiple settings, so just not allowing 
> statfs isn't necessarily enough, some other combination of things allowed and 
> denied seemed necessary to get it into that state. The one system that had 
> this had it persist across reboots but other systems never had it.  I had seen 
> it briefly happen on other systems but a reboot fixed it.
>
> I didn't put as much effort into investigating this as I might have because 
> the access in question is fairly innocuous.

I suspect this is triggered by libcap-ng's init function:
https://github.com/stevegrubb/libcap-ng/blob/master/src/cap-ng.c#L236

-- 
gpg --locate-keys dominick.grift@defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

Re: systemd and dontaudit

[Russell Coker]

On Wednesday, 23 July 2025 23:39:42 AEST Dominick Grift wrote:
> > It only happened repeatedly on one of my systems.  I think that triggering
> > that particular condition required multiple settings, so just not allowing
> > statfs isn't necessarily enough, some other combination of things allowed
> > and denied seemed necessary to get it into that state. The one system
> > that had this had it persist across reboots but other systems never had
> > it.  I had seen it briefly happen on other systems but a reboot fixed it.
> > 
> > I didn't put as much effort into investigating this as I might have
> > because
> > the access in question is fairly innocuous.
> 
> I suspect this is triggered by libcap-ng's init function:
> https://github.com/stevegrubb/libcap-ng/blob/master/src/cap-ng.c#L236

But it works most of the time while it appears that all of the systemd 
programs (most of which are in domains which dontaudit that) work.  Also in 
the case where there was a problem it happened AFTER the program had 
initialised, so the program worked for some tasks but not all and the init of 
libcapng had already happened (that's from load time right?).

That said, the fact that a common shared library expects this is a good reason 
to allow it.  Also the fact that systemd programs seem to drag in heaps of 
shared libraries at load time suggests that even if we can get it working now 
we are likely to run into a variation of the problem on another library later 
on.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/