Package: procps
Version: 2:3.3.12-3
Severity: normal
Tags: security

Following the disclosure of CVE-2017-18078, there was an elaborate
discussion on the #debian-devel and #debian-security IRC channels
regarding the scope of the vulnerability. It was then realized that
the impact of this was broader than just systemd: any time a command
like `chown -R` is ran over an untrusted directory, by root, the same
problem occurs.

This is of course mitigated by the fs.protected_hardlinks kernel
configuration, which is enforced through a patch on all the official
Debian kernels distributed by Debian, including in wheezy. See for
example:

    
https://sources.debian.org/src/linux/3.16.7-ckt20-1+deb8u3/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/
    
https://sources.debian.org/src/linux/4.14.13-1/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/

There are, however, people *not* running Debian-built kernels, and
sometimes for good reasons. This is a configuration that we should
still support.

Therefore, it seems to me we should enable this more broadly, for
example in /etc/sysctl.d/protected-hardlinks.conf. Configuring this in
user space is actually what is recommended by Linus Torvalds and the
upstream Linux kernel:

    
https://github.com/torvalds/linux/commit/561ec64ae67ef25cac8d72bb9c4bfc955edfd415

systemd ships this configuration as well, but this was deliberately
removed from Debian's systemd configuration:

    
https://salsa.debian.org/systemd-team/systemd/commit/3e1bfe0d84545557d268c1293fff0d5f3db3b5c7

I agree with the above perspective: systemd is not sufficient to
resolve that issue. We still have other init systems and we shouldn't
fix this in systemd, but in a broader package. This is why I am
proposing to fix this in procps, which ultimately owns /etc/sysctl.d/
(and /etc/sysctl.conf).

This is not a strong position: if people think this belongs in systemd
more than procps, or there is some more relevant place this can be
done *by default*, let's do it there and not quibble over that
peculiar bikeshed. :)

I would suggest adding the following configuration:

# Enable hard link protection
fs.protected_hardlinks = 1

Note that the original systemd config also enables softlink
protection:

https://salsa.debian.org/systemd-team/systemd/blob/master/sysctl.d/50-default.conf

I'm not sure if that's also relevant here so I'd keep this to
hardlinks for now to avoid unnecessary debate.

Incidentally, I wonder if we should remove the patch we have on the
Debian kernels to change the defaults, and instead rely on the
sysctl. I have added the kernel team in CC to have their input.

Thanks!

Reply via email to