Lennart Poettering <mzerqung <at> 0pointer.de> writes: > > 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...
Well, let's consider how the lock-up/deadlock would work without socket activation mechanism. Concurrent programming provides techniques like process synchronization constructs with a timeout. That would be the built-in safety mechanism that would prevent any lock-up. > ... > > 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 > This does not help in this case. The attack's effect can happen at any time and catch systemd with its pants down at any time in the scenarios you described. The attack is on socket buffer availability via kernel, it lasts until no resource is available system-wide. At that point systemd or any other socket-based communication is brought to a standstill. The point is, systemd can not be stopped, or restarted/reinitialized/reset as any other stand-alone service daemon relying on sockets availability manually. The process #1, the GOD of all processes, is incapacitated, for good. JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
