on the use of chmod/chown in maintainer scripts
Hey all,
A lot of daemon packages in Debian nowadays create their own user and groups
during installation. Usually this also implies that a couple of files and
directories are created, and then chmodded and chowned to some appropriate
value for the service in question.
In some cases[1], this chmodding and chowning is done on each package upgrade,
either because things changed over time and just doing it unconditionally seems
like the easiest thing, or just because hey, it doesn't hurt, does it?
Unfortunately, this can be a problem. Consider a tree /var/lib/example/ that
is owned or writeable by exuid. If, on upgrades, the package runs chown or
chmod -R /var/lib/example/, or does a chown or chmod on a specific node in that
tree, this implies the possibility of privilige escalation.
A process with uid exuid can just put a hardlink or symlink to
/var/lib/example/ and wait for the next package upgrade. Voila, they control
/etc/shadow.
| unbound@defiant:~$ pwd
| /var/lib/unbound
| unbound@defiant:~$ id
| uid=112(unbound) gid=120(unbound) groups=120(unbound)
| unbound@defiant:~$ rm root.key
| unbound@defiant:~$ ln -s /etc/shadow root.key
| unbound@defiant:~$ ls -l /etc/shadow
| -rw-r----- 1 root shadow 1272 May 12 11:37 /etc/shadow
[wait for the package to be upgraded]
| unbound@defiant:~$ ls -l /etc/shadow
| -rw-r----- 1 unbound unbound 1272 May 12 11:37 /etc/shadow
There are some limitations: for instance using symlinks instead of hardlinks
does not usually work when you have to rely on the ch{own,mod} being recursive
- it does work when there is an explicity change for a specific file, e.g.
/var/log/icinga/archives. Also, recent debian linux kernels carry a patch that
by default limits who can hardlink what[2]. But this will not protect users of
other kernels or people who run earlier linux versions or have that flag
disabled.
This may not be entirely trivial to solve. find | xargs constructs at best
mitigate this to a race. While chown does have a --no-derefence flag, this
does not protect us in the case of hardlinks. chmod has no such flag, and it'd
useful only for symlinks anyway. Neither tool has a --only-if-link-count-is-one
flag.
What might be needed for the general case is some means that allows packages to
securely upgrade the modes of a tree owned by them, maybe involving
fstat/fchown/fchmod and open with no-follow, also maybe in a declarative way.
Once we had that we could outlaw the use of naive chown and chmod in maintainer
scripts.
Any ideas what we should do?
Aloha,
weasel
1: I didn't do any count of the affected packages, but I come accross these
issues so often and in packages so prominent, that I feel this survey could
be delayed until we come to an agreement on whether this is an actually
issue. Examples include our exim package, ntp, stunnel4, incinga, and more.
2: fs.protected_hardlinks, see
https://lists.debian.org/20120302051158.GU12704@decadent.org.uk
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/
Reply to: