[systemd-devel] Trusting systemd vs. trusting daemons

[Lennart Poettering]

On Sat, 18.05.13 02:18, David Strauss (david at davidstrauss.net) wrote:

> 
> 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:

My take on this is to prefer systemd's code for as much as you can,
simply to make your own code simpler, and increasing code
reusing. However, there are exceptions to the rule. For example, there
are some daemons which need to do some initialization tasks with more
privileges then they need at runtime. For those it might make sense to
leave some of the chroot(), setresuid() or caps dropping to the daemons
rather than systemd. But this really depends on the specific case.  So
my recommendation is: try to use the systemd built-in priv dropping
features as far as you can, and only if you hit a wall, implement the
bits you need in the specific daemon.

> > 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.

Hmm, this wouldn't work, I fear. We could make this work though, I
guess. Added to the TODO list for now.

> > 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.

There are a number of holes in the security separation of Linux
containers. For example, setrlimit(RLIMIT_NPROC) transcends from a
specific UID used in the container UID to the same UID on the host. This
could be fixed by using USERNS in nspawn, which we currently don't, and
are unlikely to do given how seriously broken the concept is... And
there's more. You could get access to sysctls and cgroup tree stuff from
the container if you wanted to.

Some of these holes can be closed by combining things with SELinux, but
well, it's still nasty...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.