JB wrote: > Björn Persson <bjorn <at> xn--rombobjrn-67a.se> writes: > > JB wrote: > > > 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. > > > > I searched for "attack" and "socket buffer availability" trying to find > > out what kind of attack you're talking about. Duckduckgo had never heard > > about it. > > Google gave me three hits, and all three were your previous message in > > this list. It would help if you could explain how this attack works and > > how exactly it would cause SystemD to lock up. > > The link is in one of my posts above, but here it is again: > http://www.securiteam.com/unixfocus/6U00P1PEVQ.html > It contains a detailed description and the original CVE link. > Once again, it is about DOS of a resource in question, that is a socket > buffer memory, with system-wide effect, obviously on any socket-based > process. According to that description, the resource in question was physical memory. Although the attack made use of sockets, it didn't consume any kind of socket- specific resource, just plain old memory. If the attack was successful it would cause a kernel panic. A kernel panic halts the entire system. All processes stop running, regardless of whether they use sockets or not. That particular attack is therefore irrelevant in a discussion about whether process 1 should use sockets. Björn Persson
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
