Default services enabled

[Lennart Poettering]

On Tue, 23.08.11 17:48, JB (jb.1234abcd at gmail.com) wrote:

> Systemd and security - an example # 2 of an attack venue.
> ---------------------------------------------------------
> The above is dangerous as a design idea to achieve "parallelization" of
> services.
> Let's assume that service A is a dependency for service B (and others).
> After A's on-demand socket has been put "on hold" (blocking), the A may die
> or lock up for any reason, that is never to come up again by itself as
> an active service.
> That means there is a system lock-up possibility here while B (and others) are
> "on hold" too (waiting for A to be unblocked), and wait ..., and wait
> ...

A dep loop is a dep loop is a dep loop. Whether systemd is used or not
does not change this. Services with ordering loops are borked services
and won't work. If an service A synchronously calls into service B and
the service B synchronously calls into A you'll have a dealock. No news
there...

> We know that systemd owns the service socket-in-waiting (with its buffer).
> In case of an attack on socket buffer availability via kernel the systemd is
> grounded as well.
> This should not be allowed to happen to process #1, the Mother of All
> Processes.
> One more reason to redesign the systemd to be minimal and "beyond approach",
> and instead have other restartable "child" process(es) take over the function
> of on-demand socket handling.
> 
> Can you comment on that ?

systemd enforces limits on the number of sockets it keeps open. If you
have a socket unit with Accept=yes (i.e. where systemd will accept() the
socket and spawn one service instance per connection) then you can
enforce a limit with MaxConnections= which defaults to 64.

And on socket units with Accept=no (the much nicer way, where systemd
will spawn a single instance and hand over the listening fd), this
problem doesn't exist at all, since we only keep a single fd per unit
open.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.