Default services enabled

[JB]

JB <jb.1234abcd <at> gmail.com> writes:

> ...

Here are some more detailed thoughts.

Sys init.
--------- 
Sys init as a process #1 should be "beyond approach" by design, and delegate
all work to other process(es), whether in a permanent or an ad-hoc manner,
that can be operated by sysadmin if needed (e.g. restarted, initialized,
configured, fixed, etc).
We want it to be minimal in its size, minimal in its functions, simple,
stable, secure (no attack venues, direct or indirect) - yes,
"beyond approach".

Sockets activation and on-demand services. 
------------------------------------------
Here is a description of how it works:
http://0pointer.de/blog/projects/socket-activation.html

The essense begins here:
"Socket activation makes it possible to start all (...) services completely
simultaneously, without any kind of ordering.
...
That means the scheduling of our services is entirely done by the kernel: ,,," 

Then it continues:
"But it's not just about parallelization. It offers a number of other
benefits:
  ...
  We no longer need to configure dependencies explicitly. Since the sockets
  are initialized before all services they are simply available ...

  If a service dies its listening socket stays around, not losing a single
  message. After a restart of the crashed service it can continue right where
  it left off.
  ..."

Well, it looks like a "wunderwaffe" :-)

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 ...

Systemd and security - an example # 1 of an attack venue.
---------------------------------------------------------
Here is a possible known example:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html

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 ?

JB

http://news.icanhascheezburger.com/2010/06/22/political-pictures-make-a-windows-that-doesnt-crash/