Default services enabled

[Björn Persson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110824/defa5085/attachment.bin