On Thu, May 16, 2013 at 11:39 PM, Aaron Faanes <dafr...@gmail.com> wrote: > So my question, simply, is this: Should I prefer running a process as > root knowing that it chroots itself, or should I run it as non-root > and chroot it via systemd?
I support the "trust systemd; don't trust the daemon" model going forward. It's not because systemd has impeccable security, it's because of the following: * systemd contains one heavily reviewed implementation of privilege management, while daemons get varying levels of scrutiny. rsync has probably received decent scrutiny here. * Many daemons drop privileges using set seteuid(), which leaves open a root escalation path if someone finds any arbitrary execution exploit in the daemon. * If you're an administrator, you're more likely to get things right if you learn a common way to configure things with systemd rather than learning each daemon's own model. * systemd supports restrictions that are generally more powerful than simply dropping root privileges and chroot. You can also integrate with MAC frameworks and syscall filtering. * Most restrictions systemd puts in place actually just configure restrictions managed in the kernel (whether UID-based, selinux-based, or syscall filtering-based), so you're not changing the attack surface for systemd-managed security versus daemon-managed security. systemd has a suite of tools to enable services to have fewer permissions than every before, even in terms of the directories they'd need access to: * The systemd "simple" service model doesn't require PID files. * The journal allows advanced logging without access to files. Access is only necessary to stdout/stderr, the syslog socket, or the journal socket. Logs get automatically bound to the applicable service. * Socket activation, as you noticed, allows a service to listen on any port without starting as root. * Resource limits can get set by systemd without the daemon needing to make such syscalls. > While I'm at it, one thing I'd like to do is construct a whitelist like this: > > InaccessibleDirectories=/ > ReadOnlyDirectories=<stuff I'm serving> This is a great question, and something I've wondered myself. It shouldn't be hard to try empirically. Don't forget SecureTmp= and PrivateNetwork= as well. The former is just good sense, and the latter should work well if the only network communication rsync needs to do is over the socket systemd passes in. > I would run this service using systemd-nspawn if I wanted to maximize > security at the cost of simplicity. systemd-nspawn isn't designed for secure containerization, but I'd have to search a bit to enumerate why. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
