[systemd-devel] Trusting systemd vs. trusting daemons

[David Strauss]

On Thu, May 16, 2013 at 11:39 PM, Aaron Faanes <dafrito at 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
   | david at davidstrauss.net
   | +1 512 577 5827 [mobile]