Re: Systemd Security
On Thu, 06.10.16 12:33, Ivan Chavero (ichavero(a)redhat.com) wrote:
Setting a umask of 0 means that, by default, any file created by
systemd
will be world-readable and -writable. Systemd defines a macro called RUN_WITH_UMASK
which is used to temporarily set a more restrictive umask when systemd needs to create
a file with different permissions. This is backwards. The default umask should be
restrictive,
so forgetting to change the umask when creating a file would result in a file that
obviously
doesn't work. This is called fail-safe design.
Well, for starters umask isn't really usable in non-trivial system
service. It's per-process, not per-thread. This means changing it all
the time is problematic, since if you want to do it properly, you'd
have to add locking around it and make sure that any code touching the
umask is nice enough to care and take the lock, too.
This one major reason most daemons actually decide to turn off the
umask entirely, and just make the last argument of open() or mknod()
count as it is. Of course, if your daemon is trivial, and only ever
has one thread, then umask is fine, but the world isn't like that.
Now, PID 1 in systemd itself is pretty much single-threaded in
theory. The thing though is that a number of Linux ioctls are blocking
in nature. This means if you want to integrate them into a proper,
asynchronous event loop you don't really have any other option than to
run them in a thread or subprocess. Hence systemd maintains threads
for that after all. I wish we wouldn't have to... (Many of the VT and
autofs ioctls are blocking, as two examples). But many of the kernel
folks never touched userspace code, and didn't really get the message
yet that blocking kernel API are a bad idea in 2016 -- see the new
getrandom() syscall for example.
Guides such as the original "Linux Daemon Writing" HOWTO also suggest
turning off umask -- google for it. (And so does daemon(7) actually,
as shipped with systemd)
In systemd we generally avoid munging with umask or relying on it for
the above reasons. But then there's also the problem that a number of
library calls and syscalls don't allow passing the file mode for nodes
in the file system that shall be created. Most prominently that is
bind() when used for creating AF_UNIX sockets in the file
system. Since there's no other way to race-freely ensure the right
file modes, in this case we actually *do* mangle the umask, and that's
what RUN_WITH_UMASK is for, but only this.
Or in other words: in a very simple world, yeah, umask is fine. But
the real world is much more complex, and in this real world umask is
just broken when applied to system services. The author of that blog
story doesn't really know what he is talking of. It would have been a
good idea for him to first read up on things before starting to bitch
how stupid the systemd devs are.
Lennart
--
Lennart Poettering, Red Hat