Default services enabled

Sat Aug 20 19:31:25 UTC 2011

On Saturday, August 20, 2011 02:17:04 PM Lennart Poettering wrote:
> On Sat, 20.08.11 09:41, Steve Grubb (sgrubb at redhat.com) wrote:
> > On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote:
> > > Tim Waugh wrote:
> > > > Oh, I just noticed this:
> > > > 
> > > > https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_ac
> > > > tiva tion "Since Fedora currently doesn't want any services to do
> > > > on-demand loading, all socket activated services must autostart."
> > > 
> > > What the heck?! We're disabling systemd's main feature there, aren't
> > > we? Wasn't the main design concept behind systemd the observation that
> > > everything can be parallelized most effectively by on-demand
> > > activation?
> > 
> > Why is bootup speed so important that init now has become network aware?
> > Process 1 gets special protection from the kernel. You cannot kill it.
> > If there is any mistake in its code, then you have an unkillable all
> > powerful process that might do rogue things. It almost sounds like this
> > is reinventing Xinetd - except its not as feature rich as xinetd.
> 
> systemd never reads a single packet from any of the network sockets it
> listens on on behalf of services. It just passes these sockets off to
> the services as soon as traffic is seen on them (i.e. when POLLIN is
> triggered we pass off the socket, we don't call read() on it.)

And therein lies one of the big problems that xinetd has. If its listening and passes 
the descriptor to a child to accept and the child crashes or aborts before accepting 
the socket, the whole mess spins in a circle where the listen descriptor is readable, 
but nothing is accepting the connection.

But still, why is speed so important that xinetd capabilities are the answer? Why not 
leave init not network aware and let xinetd do the on demand startup? This has the 
advantage of being able to kill xinetd whereas init cannot be killed.

> > Then lets look at the accept option. If systemd accepts a connection and
> > passes it to a child process, do you now support tcp_wrappers so that
> > you deny the connection before starting the child?
> 
> We do tcpwrap checks for incoming connections. I do wonder though
> whether it might be time to deprecate tcpwrap distribution-wide. I am
> pretty sure firewalls are the better approach, more widely supported,
> more widely understood and more widely used.

Do you remember the hole in netfilter a while back? 
CVE-2001-1572 
CVE-2006-4572
Its happened before and it will happen again. I'm sure this list is not complete.

Then some tools that help setup the firewall might accidentally leave you open:
CVE-2003-0080

Belt and suspenders! Must have both.

> > That would mean any flaw in tcp_wrappers now is part of process 1
> > which has special protection from the kernel.
> 
> We are very careful with what we execute in PID 1. For example we make
> sure not to do any NSS lookups or use other code that might pull in
> arbitrary libraries into PID 1. And following this logic I carefully
> made sure that tcpwrap checks are not done in PID 1, but in the forked
> off process shortly before we execute the process binary.
> 
> And anyway, I wouldn't overestimate the risk here. tcpwrap does not read
> from the socket, it just executes syscalls like getsockname() and
> getpeername() and suchlike, but does not parse potentially dangerous
> network traffic.

I wrote lots of patches for tcp_wrappers, mostly to give it ipv6 capabilities. But 
there were bugs fixed. For example, it provides many functions with names that are in 
glibc. Which means you might get tcp_wrapper's implementation rather than glibc's. My 
version was called socket_wrappers and it fixed a whole lot of the problems in 
tcp_wrapper. So, even if you fork with the intention of not using its code in process 
1, you might accidentally be using it.

readelf -s /lib64/libwrap.so.0.7.6 | grep FUNC | grep -v UND

Looks like someone has been doing some cleanining up, but maybe not that way on other 
distros.

But anyways, tcp_wrapper does reverse DNS lookups to compare the forward and reverse 
paths in case anyone has tampered with the remote DNS to make it look like the 
incoming connection is legit. So, may it does not read much off the socket, its does a 
recvfrom peek, but it does talk with remote DNS servers to make a decision. Not all 
DNS servers are legit and can be malicious. One incoming packet can cause a cascade of 
outgoing DNS querries.

> > I personally think systemd's configure should have an
> > --enable-networking. I think this should be turned off. A network aware
> > init could be internet worm material since you cannot kill process 1.
> 
> Please read up on socket activation before making such broad comments.

I feel very comfortable in saying that if you increase the attack surface of an 
unkillable and all powerful process, someone will notice this and find the hole one day 
and it might not even be in your code. You may do everything perfect and there is one 
hole in a library that is the undoing of the system. The difference is an IPS system 
can reach out and kill a normal inetd daemon...but not if its init.

> http://0pointer.de/blog/projects/systemd.html
> 
> Read the part about "Parallelizing Socket Services". It explains why
> socket actviation is interesting, 

I find a secure OS interesting. Bootup speed does not matter much to me.

-Steve