On Mon, 22.08.11 17:19, Adam Williamson (awilliam@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
