Re: [systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?
Am 14.08.19 um 12:48 schrieb Michael Chapman: > On Wed, 14 Aug 2019, Reindl Harald wrote: may is ask you to read the thread you are responding to? nobody is touching the private socket >>> >>> systemctl will mostly use /run/systemd/private when run as root >> >> that's not the point - the point is his talking about "doesn't private >> socket mean" when the code triggering in the thread the issue don't talk >> to it directly > > I don't know who specifically you are referring to. > > Brian's example, when run as root, connects to systemd using the private > socket. When run as an unprivileged user it will go via the DBus daemon > instead. sh -c 'exec 1>&-; /usr/bin/systemctl status ntpd.service' that code don#t talk directly to that socket and so any "but doesn't private socket mean it's intended to be used by systemd only" is nonsense give it is used by systemd in the form of systemctl ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?
On Wed, 14 Aug 2019, Reindl Harald wrote: > Am 14.08.19 um 12:41 schrieb Michael Chapman: > > On Wed, 14 Aug 2019, Reindl Harald wrote: > >> Am 14.08.19 um 12:10 schrieb Ulrich Windl: > >> Michael Chapman schrieb am 14.08.2019 um > >> 11:47 in > 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. > >>> > >>> 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... > >> > >> may is ask you to read the thread you are responding to? > >> nobody is touching the private socket > > > > systemctl will mostly use /run/systemd/private when run as root > > that's not the point - the point is his talking about "doesn't private > socket mean" when the code triggering in the thread the issue don't talk > to it directly I don't know who specifically you are referring to. Brian's example, when run as root, connects to systemd using the private socket. When run as an unprivileged user it will go via the DBus daemon instead. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?
Am 14.08.19 um 12:41 schrieb Michael Chapman: > On Wed, 14 Aug 2019, Reindl Harald wrote: >> Am 14.08.19 um 12:10 schrieb Ulrich Windl: >> Michael Chapman schrieb am 14.08.2019 um 11:47 >> in 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. >>> >>> 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... >> >> may is ask you to read the thread you are responding to? >> nobody is touching the private socket > > systemctl will mostly use /run/systemd/private when run as root that's not the point - the point is his talking about "doesn't private socket mean" when the code triggering in the thread the issue don't talk to it directly ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?
On Wed, 14 Aug 2019, Reindl Harald wrote: > Am 14.08.19 um 12:10 schrieb Ulrich Windl: > Michael Chapman schrieb am 14.08.2019 um 11:47 > in > >> 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. > > > > 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... > > may is ask you to read the thread you are responding to? > nobody is touching the private socket systemctl will mostly use /run/systemd/private when run as root. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?
On Wed, 14 Aug 2019, Ulrich Windl wrote: > >>> Michael Chapman schrieb am 14.08.2019 um 11:47 in > Nachricht : > > 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 Any user can connect to it at least. systemd will drop the connection if it's from an unprivileged client. The question though is whether junk data still pending on that connection will cause systemd to leak the file descriptor. I think we'd need to fully understand why the problem occurred on older systemd versions to be able to answer that. Maybe that problem has been fixed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?
Am 14.08.19 um 12:10 schrieb Ulrich Windl: Michael Chapman schrieb am 14.08.2019 um 11:47 in >> 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. > > 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... may is ask you to read the thread you are responding to? nobody is touching the private socket Weitergeleitete Nachricht Betreff: Re: [systemd-devel] systemd's connections to /run/systemd/private ? Datum: Tue, 13 Aug 2019 17:50:56 -0400 Von: Brian Reichert An: Zbigniew J??drzejewski-Szmek Kopie (CC): systemd-devel@lists.freedesktop.org This is sufficient to reproduce the effect of increasing the number of file descriptors open to /run/systemd/private; at least, on my box, in it's current state: sh -c 'exec 1>&-; /usr/bin/systemctl status ntpd.service' We have cronjob that closes STDOUT, remaps STDERR to a log file, and runs this systemctl command. In my environment, this one-liner will cause that FD count to go up by, 100% reproducible ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?
>>> Michael Chapman schrieb am 14.08.2019 um 11:47 in Nachricht : > 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
