[systemd-devel] [PATCH] timesyncd: tighten unit file

[Lennart Poettering]

On Tue, 27.01.15 21:58, Topi Miettinen (toiwoton at gmail.com) wrote:

> > Well, to enable stateless systems I think it is a good idea to write
> > services in a way that they can rebuild what they need in /var on
> > their own, should it be missing, so that /var can be flushed out and
> > things will just work when the machine is then booted again.
> > 
> > All our daemons are written in a style where /var is reconstructed
> > implicitly if it is missing, and timesyncd really should work the same
> > way.
> 
> Nice, but the directories could be created with tmpfiles.d then?

Well, we could. But I really like robust deamons that just work on
their own, I must say...

> > Well, the way I read the paragraph above if we set PR_SET_NO_NEW_PRIVS
> > after forking, but before execing systemd-timesyncd, and that binary
> > has an selinux label on it, that the selinux label would be ignore,
> > and things would continue to run with the same label as we forked
> > off. This pretty much renders SELinux usesless, since all services
> > where we set the bit for would then run as "init_t"... and that's
> > something we really shouldn't do.
> 
> seccomp_filter.txt on the other hand says that
> "Prior to use, the task must call prctl(PR_SET_NO_NEW_PRIVS, 1) or
> run with CAP_SYS_ADMIN privileges in its namespace.  If these are not
> true, -EACCES will be returned.  This requirement ensures that filter
> programs cannot be applied to child processes with greater privileges
> than the task that installed them."
> 
> Does this mean that SELinux and seccomp are mutually exclusive? Awful
> design if so.

Well, no it doesn't mean that. If systemd sets up a seccomp filter it
has CAP_SYS_ADMIN, hence all is good. And it can leave
PR_SET_NO_NEW_PRIVS off, and thus not break selinux.

> > If Apparmor policies are standardized and stand-alone enough, and
> > there's a clear way to install them, and you are willing to look after
> > it, then yes, I'd merge a patch that adds apparmor profiles to systemd
> > upstream.
> 
> Well, I'm no expert on AppArmor policies. This is what I have:
> 
> #include <tunables/global>
> 
> /lib/systemd/systemd-timesyncd {
>   #include <abstractions/nameservice>
> 
>   capability setgid,
>   capability setuid,
>   capability sys_time,
>   capability setpcap,

this is missing the three fs related caps at least...

>   /etc/ld.so.cache r,
>   /etc/systemd/timesyncd.conf r,
>   /lib/systemd/systemd-timesyncd mr,
>   /lib/x86_64-linux-gnu/libattr.so.* mr,
>   /lib/x86_64-linux-gnu/libc-*.so mr,
>   /lib/x86_64-linux-gnu/libcap.so.* mr,
>   /lib/x86_64-linux-gnu/libm-*.so mr,
>   /lib/x86_64-linux-gnu/libnsl-*.so mr,
>   /lib/x86_64-linux-gnu/libpthread-*.so mr,
>   /lib/x86_64-linux-gnu/libresolv-*.so mr,
>   /proc/cmdline r,
>   /proc/sys/kernel/random/boot_id r,
>   /run/systemd/netif/state r,

This is not sufficient, as it also wants to read the networkd
confguration, to get NTP servers from it, if networkd is running.

Anyway, if this is cleaned up, and overlooked by somebody who knows
apparmor, and is properly installed by automake, i'd take a patch for
this. However, as i have no clue of Apparmor and can't test this I'd
fully rely on contributions for this one.

Lennart

-- 
Lennart Poettering, Red Hat