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

[Lennart Poettering]

On Sun, 01.02.15 09:28, Topi Miettinen (toiwoton at gmail.com) wrote:

> On 01/27/15 22:19, Lennart Poettering wrote:
> > On Tue, 27.01.15 21:58, Topi Miettinen (toiwoton at gmail.com) wrote:
> >>> 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.
> 
> So in conclusion, only the SecureBits part would be interesting. Looking
> at the unit files, which of them expect to run setuid helpers? I looked
> at the unit files and briefly at the corresponding programs (also to get
> to know them better), so I offer my guesses below:

In general, I would only bother with setting the securebits for
long-running services. The stuff that only sets up something and
quickly exits is probably not worth the efforts...

Also, anything that invokes generic user code (such as the gettys or
logind) can't really be locked down, since we should not restrict what
the users can do.

I'd also not bother with debugging/profiling tools such as bootchart,
since they aren't part of normal code paths.

Which means I think only these really remain:

> units/systemd-hostnamed.service.in

> units/systemd-importd.service.in
> 
> Calls systemd-importd, which in turn executes several helpers,
> especially gpg which could be setuid to lock memory, so no.

Actually, importd already drops most caps on its own. It even takes
most caps away from gpg... I think it is safe to use securebits on this.

> units/systemd-journald.service.in
> units/systemd-journal-gatewayd.service.in
> units/systemd-journal-remote.service.in
> units/systemd-journal-upload.service.in
> units/systemd-localed.service.in
> units/systemd-logind.service.in
> units/systemd-machined.service.in
> units/systemd-networkd.service.in
> units/systemd-resolved.service.in
> units/systemd-timedated.service.in
> units/systemd-timesyncd.service.in

I think adding the securebits stuff should be safe for all of these...

Lennart

-- 
Lennart Poettering, Red Hat