On 12/4/20 1:44 AM, Dale wrote:
Will opentmpfiles be fixed at some point or is it true that it can't be
fixed? On -dev, I think I read where one person said it can't be
fixed. In that case, switching is likely a good idea since the insecure
package can't be fixed.
The answer is a bit complicated. The first thing we need to understand
that opentmpfiles is supposed to be a cross-platform (i.e. POSIX)
implementation of the systemd-tmpfiles program. Systemd itself only runs
on newer versions of linux, and since it has control of the entire
system, it can enable those non-standard symlink and hardlink
protections. So,
* systemd-tmpfiles is secure, but only on linux, and only if you let
it enable fs.protected_hardlinks for you.
The security there comes from two places. The first is that everything
was implemented carefully in C to avoid these problems, and the second
is that fs.protected_hardlinks solves the otherwise-unavoidable hardlink
exploits.
Now for contrast, opentmpfiles is INsecure for two reasons:
(1) It's written in shell script, so it doesn't have the ability to
pass e.g. O_NOFOLLOW to all of the calls that might follow
symlinks. And shell programs all operate on path names as opposed
to file descriptors, so race conditions are impossible to avoid.
(2) The fs.protected_hardlinks sysctl is not cross-platform, so if
it's to fulfill its stated design goals, opentmpfiles can't rely
on fs.protected_hardlinks.
The first problem is fixable, but the second is not. If opentmpfiles is
rewritten in C, it could be just as secure as systemd-tmpfiles... but
**only on linux with fs.protected_hardlinks enabled**.
It will never be both secure and cross-platform. The design of the whole
tmpfiles.d thing is flawed in that regard.
root@fireball / # sysctl -n fs.protected_hardlinks
1
root@fireball / #
Does that improve things any or does that not really help anything?
It completely fixes one of the problems (hardlinks), but does nothing
for the other (non-terminal symlinks).
