Mailing List Archive: mod_systemd: refactor to get rid of libsystemd dependency?

mod_systemd: refactor to get rid of libsystemd dependency?

Apr 2, 2024, 3:25 AM

Post #1 of 5 (140 views)

Hi there,

in the light of the recent xz attack I was wondering, whether we should
also reduce our library dependencies by no longer using sd_notify() in
mod_systemd (thus loading libsystemd and all of its dependencies), but
instead taking the approach to hard code sd_notify functionality.

I guess the Linux distributors who patched sshd to use libsystemd for
notification are on their way to do the same for their sshd patches, so
we might soon get an idea how to do that properly.

This is not meant to become part of out next release (this week), but
hopefully we can manage to code it for the next one.

WDYT: does this make sense?

A little bit of technical background is contained in

https://news.ycombinator.com/item?id=39867126

Best regards,

Rainer

Re: mod_systemd: refactor to get rid of libsystemd dependency? [ In reply to ]

jorton at redhat

Apr 3, 2024, 7:32 AM

Post #2 of 5 (126 views)

Permalink

On Tue, Apr 02, 2024 at 12:25:40PM +0200, Rainer Jung wrote:
> Hi there,
>
> in the light of the recent xz attack I was wondering, whether we should also
> reduce our library dependencies by no longer using sd_notify() in
> mod_systemd (thus loading libsystemd and all of its dependencies), but
> instead taking the approach to hard code sd_notify functionality.
>
> I guess the Linux distributors who patched sshd to use libsystemd for
> notification are on their way to do the same for their sshd patches, so we
> might soon get an idea how to do that properly.
>
> This is not meant to become part of out next release (this week), but
> hopefully we can manage to code it for the next one.
>
> WDYT: does this make sense?

The trunk mod_systemd has got slightly wider library use than just
sd_notify - so it is not quite that simple. If there was an alternative
minimal library implementing the sd_* API parts required, that would
definitely make sense. I'm not sure that reimplementing them all from
scratch makes sense (especially multiplied by N projects doing this).

It looks like systemd folks have also changed the library implementation
to dlopen() the various dependant libraries on demand now rather than
directly linking to them, which removes the specific attack vector used
here IIUC.

Regards, Joe

Re: mod_systemd: refactor to get rid of libsystemd dependency? [ In reply to ]

dev at httpd

Apr 3, 2024, 7:58 AM

Post #3 of 5 (126 views)

Permalink

On 02 Apr 2024, at 11:25, Rainer Jung <rainer.jung@kippdata.de> wrote:

> in the light of the recent xz attack I was wondering, whether we should also reduce our library dependencies by no longer using sd_notify() in mod_systemd (thus loading libsystemd and all of its dependencies), but instead taking the approach to hard code sd_notify functionality.
>
> I guess the Linux distributors who patched sshd to use libsystemd for notification are on their way to do the same for their sshd patches, so we might soon get an idea how to do that properly.
>
> This is not meant to become part of out next release (this week), but hopefully we can manage to code it for the next one.
>
> WDYT: does this make sense?

Definite +1.

The attack surface on systemd has always been too big, now is the time to fix that.

Regards,
Graham
--

Re: mod_systemd: refactor to get rid of libsystemd dependency? [ In reply to ]

rpluem at apache

Apr 4, 2024, 2:43 AM

Post #4 of 5 (124 views)

Permalink

On 4/3/24 4:32 PM, Joe Orton wrote:
> On Tue, Apr 02, 2024 at 12:25:40PM +0200, Rainer Jung wrote:
>> Hi there,
>>
>> in the light of the recent xz attack I was wondering, whether we should also
>> reduce our library dependencies by no longer using sd_notify() in
>> mod_systemd (thus loading libsystemd and all of its dependencies), but
>> instead taking the approach to hard code sd_notify functionality.
>>
>> I guess the Linux distributors who patched sshd to use libsystemd for
>> notification are on their way to do the same for their sshd patches, so we
>> might soon get an idea how to do that properly.
>>
>> This is not meant to become part of out next release (this week), but
>> hopefully we can manage to code it for the next one.
>>
>> WDYT: does this make sense?
>
> The trunk mod_systemd has got slightly wider library use than just
> sd_notify - so it is not quite that simple. If there was an alternative
> minimal library implementing the sd_* API parts required, that would
> definitely make sense. I'm not sure that reimplementing them all from
> scratch makes sense (especially multiplied by N projects doing this).
>

+1

> It looks like systemd folks have also changed the library implementation
> to dlopen() the various dependant libraries on demand now rather than
> directly linking to them, which removes the specific attack vector used
> here IIUC.
+1. Unless the systemd folks show that they are unwilling to address issues
I would stay with libsystemd.

Regards

Rüdiger

Re: mod_systemd: refactor to get rid of libsystemd dependency? [ In reply to ]

jim at jaguNET

Apr 4, 2024, 6:49 AM

Post #5 of 5 (122 views)

Permalink

+1

> On Apr 4, 2024, at 5:43?AM, Ruediger Pluem <rpluem@apache.org> wrote:
>
>
>
> On 4/3/24 4:32 PM, Joe Orton wrote:
>> On Tue, Apr 02, 2024 at 12:25:40PM +0200, Rainer Jung wrote:
>>> Hi there,
>>>
>>> in the light of the recent xz attack I was wondering, whether we should also
>>> reduce our library dependencies by no longer using sd_notify() in
>>> mod_systemd (thus loading libsystemd and all of its dependencies), but
>>> instead taking the approach to hard code sd_notify functionality.
>>>
>>> I guess the Linux distributors who patched sshd to use libsystemd for
>>> notification are on their way to do the same for their sshd patches, so we
>>> might soon get an idea how to do that properly.
>>>
>>> This is not meant to become part of out next release (this week), but
>>> hopefully we can manage to code it for the next one.
>>>
>>> WDYT: does this make sense?
>>
>> The trunk mod_systemd has got slightly wider library use than just
>> sd_notify - so it is not quite that simple. If there was an alternative
>> minimal library implementing the sd_* API parts required, that would
>> definitely make sense. I'm not sure that reimplementing them all from
>> scratch makes sense (especially multiplied by N projects doing this).
>>
>
> +1
>
>> It looks like systemd folks have also changed the library implementation
>> to dlopen() the various dependant libraries on demand now rather than
>> directly linking to them, which removes the specific attack vector used
>> here IIUC.
> +1. Unless the systemd folks show that they are unwilling to address issues
> I would stay with libsystemd.
>
> Regards
>
> Rüdiger