Package: dh-runit Version: 2.8.13.2 Tags: security Control: affects -1 tor openssh-server
by default, dh-runit sets up logging runscripts like this:
------------
1 #!/bin/sh
2 chown -R runit-log:adm '/var/log/runit/tor'
3 chmod 750 '/var/log/runit/tor'
4 chmod u+rw,g+r,o-rwx '/var/log/runit/tor'/*
5 exec chpst -u runit-log svlogd -tt '/var/log/runit/tor'
------------
Lines 2 and 4 are dangerous due to linking attacks.
hardlinks and chown (line 2)
----------------------------
If /var/log/runit/tor happens to be on the same filesystem as another
interesting file, and fs.protected_hardlinks is not set to 1, then the
runit-log user can get read/write access to that data by hard-linking to
it, and waiting for line 2 to trigger at the next launch of the logging
process.
Even if fs.protected_hardlinks is set to 1, line 2 permits the runit-log
user to gain ownership of any file in the same filesystem that they
merely have read-write access to.
Note that fs.protected_hardlinks just protects *creation* of a hardlink
while that sysctl property is set. So even a single reboot into a
kernel with fs.protected_hardlinks=0 by default, or a brief switch to
fs.protected_hardlinks=0 provides a window of opportunity for the
hardlink to be created, which sets the stage for the subsequent
compromise when this runscript is launched again later. As long as the
link is made, the compromise happens at the next launch, even if
fs.protected_hardlinks is back to 1 at that point.
symlinks and chmod (line 4)
---------------------------
line 4 permits the runit-log user to change the permissions in the
specified way on *any* file in the filesystem, just by symlinking to
that file from within the specified directory. from chmod(1):
However, for each symbolic link listed on the command line, chmod
changes the permissions of the pointed-to file. In contrast,
chmod ignores symbolic links encountered during recursive
directory traversals.
fs.protected_symlinks=1 offers no protection against this because
/var/log/runit/tor/ is not a sticky world-writable directory.
granted, these are fairly standard constrained permissions, and won't be
a serious security risk for many files, but it is a surprising side
effect that the runit-log user gets this sort of power over any file
anywhere in the filesystem.
how to fix
----------
It is a better policy to non-recursively chown/chmod the top-level
directory (/var/log/runit/tor in this example) and to not touch any file
below there.
If that strategy fails, it fails because something is already wrong in
that directory.
If the goal of this promiscuous chown/chmod action is to provide group
adm with read access to the files in question, it is better to have the
runit-log user do that explicitly (i.e. to implement it in svlogd,
perhaps with acls?).
--dkg
signature.asc
Description: PGP signature
