Default services enabled

[Steve Clark]

On 08/20/2011 03:31 PM, Steve Grubb wrote:
> 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
Obviously a lot on this list value boot up speed over security!

-- 
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110821/bc2f6d9f/attachment.html