Antw: Re: systemd's connections to /run/systemd/private ?

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Michael Chapman <mike@xxxxxxxxxxxxxxxxx> schrieb am 14.08.2019 um 11:47 in
Nachricht <alpine.LFD.2.21.1908141941560.3528@xxxxxxxxxx>:
> On Wed, 14 Aug 2019, Lennart Poettering wrote:
>> Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
>> really bad idea in general. That systemctl nowadays is particularly
>> careful and deals with situations like that is not an invitation to
>> actually invoke things like this. After all UNIX guarantees that
>> open() (and the other calls that allocate an fd) allocated the lowest
>> available one, hence they will necessarily step into
>> stdin/stdout/stderr territory when invoked with any of those fds
>> closed.
>> 
>> Hence: your code that closes fd1 like this is simply buggy. Don't do
>> that, you are shooting yourself in the foot. And even if newer
>> systemctl will handle cases like this more gracefully pretty much any
>> other tool you might call will break in some form or another too,
>> since a simple printf() will already spill into the wrong fds in that
>> case.
>> 
>> Lennart
> 
> That's all true, but the thing we need to check here is that systemd 
> correctly handles junk on the /run/systemd/private socket. The change on 
> the systemctl side certainly tries to prevent incorrect data being sent 
> down the socket -- though it looks like there's several ways in which 
> fd_move_above_stdio() can fail, so this isn't foolproof -- but we need to 
> ensure that some _malicious_ client can't DoS systemd.

Hi!

I don't want to contradict in principle, but doesn't "private socket" mean it's intended to be used by systemd only? Of course being root allows you to use any socket...

I could imaging two things of torture testing:
1) send random data to the socket and see what happens.
2) vary valid messages randomly to see what happens

(1 may take longer time, but will be more thorough, while 2 while be fast without catching all possible mis-interpretation)

Regards,
Ulrich

> _______________________________________________
> systemd-devel mailing list
> systemd-devel@xxxxxxxxxxxxxxxxxxxxx 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 




_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel