[systemd-devel] systemd's connections to /run/systemd/private ?

[Lennart Poettering]

On Mi, 14.08.19 19:47, Michael Chapman (mike at very.puzzling.org) wrote:

> 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.
>
> 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.

Well, a D-Bus connection can remain open indefinitely, and may even
have incomplete "half" messages queued in them as long as the client
desires. After the initial authentication is done, clients may thus
take up resources as long as they want, this is by design of dbus
really, and is different from HTTP for example, where connections
usually have a time-out applied. dbus doesn't know timeouts for
established connections. It knows them for the authentication phase,
and it knows them for method calls that are flight, but it does not
know them for the mere existance of an established connection.

PID 1 authenticates clients of the private connection simply by making
the socket for it inaccessible to anyone who is not privileged. Due to
that it gets away with not doing any further per-user accounting,
because it knows the clients are all privileged anyway.

So, yes, it would be good if we could protect us from any form of
misuse, but basically, if you have a root client that misbehaves you
have too accept that...

Lennart

--
Lennart Poettering, Berlin