On Tue, 23.08.11 17:48, JB (jb.1234abcd@xxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
