Default services enabled

Lennart Poettering mzerqung at 0pointer.de
Tue Aug 23 00:32:57 UTC 2011


On Mon, 22.08.11 17:19, Adam Williamson (awilliam at redhat.com) wrote:

> 
> On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote:
> > On 08/22/2011 07:07 PM, Adam Williamson wrote:
> > > On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
> > > 
> > >>> -Steve
> > >> Obviously a lot on this list value boot up speed over security!
> > > 
> > > You're making a false assumption, which is that socket activation is
> > > only about speed. It's also about resource usage. (There may be other
> > > advantages I haven't considered, this is not to be considered an
> > > exclusive list.)
> > 
> > 
> >   Mmmm Adam - not sure I'd give up security for a little resource saving
> > either ... if indeed that is the trade-off ...
> 
> Well, there's a question of whether you're really giving up security.
> There's no actual vulnerability at issue here, just the theory that
> systemd is more susceptible to vulnerabilities.

As mentioned a couple of times systemd does not read a single network
packet, hence I'd claim systemd is no worse than sysvinit+xinetd+a lot
of stuff, yet a lot more powerful. (xinetd processes a lot of crazy
network protocols internally, and one could argue that it hence is
actually much worse here than systemd. Also, since it duplicates service
execution in two daemons the amount of code to audit is doubled.)

In fact, systemd offers quite a number security features to secure your
services wich can be easily used to enhance local security. I'll
probably blog about this soonishly, but there's a lot of nice stuff in
there. For example, set "PrivateNetwork=yes" in a service file and the
service will be entirely cut off from the network, so that no network
interfaces are visible anymore. It will only have access to a private,
isolated instance of the loopback device. This is something we should
set for a number of services which never should get network access, like
upower, dbus, or colord. Another really simple option like this is
"PrivateTmp=yes" which gives the service a private, isolated /tmp
directory, so that it won't see and cannot access other processes'
files. Stuff like this is really easy to use, and brings immediate
security benefits, since it locks services into flexible jails,
minimizing the attack surface and locking in exploiters.

I am sure that in sum systemd is a net benefit for security.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list