On Sat, 18.05.13 02:18, David Strauss (da...@davidstrauss.net) wrote: > > 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:
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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel