Bug#225692: A common setuid symlink issue, and possible patch to the bug

[Erno Kuusela <erno@iki.fi>]

hello,

On Sun, 04 Jan 2004, Javier Fernández-Sanguino Peña wrote:

| > | I'm not sure if this bug should qualify as 'grave' since it's not dpkg
| > | task to control who symlinks to potentially dangerous binaries. As
| > 
| > no, but dpkg could handle the upgrade / safe neutralization of old setuid
| > binaries in the manner i described, and it doesn't.
| 
| Still, it's a wishlist bug, you are asking for an improvement to solve a 
| security situation.

well, the current situation yields local root vulnerabilities, thus it
is clearly a bug in the system. from my laymans point of view this is
dpkg's responsibility since it's replacing the binaries on upgrade.
i don't see why it would be a "wishlist" bug.

| Notice that proper partitions _are_ one way to fix this issue [2]. Even if
| you fix dpkg you are still prone to DoS attacks and hardlink attacks to
| local binaries (/usr/local) not handled by dpkg (or even by installation of
| local binaries if you do it in /usr/ but do not use debian packages)

i guess install(1) should be fixed as well. /usr/local stuff and other
third party stuff is beyond debian's control anyhow, responsibility
is on the third party packages.

[from the next mail]
| Notice that my proposal is to chmod the setuid bit just before it's
| unlinked in the dpkg code. When a binary is substituted it's first renamed
| (link/rename) and then removed, the chmod bit should be removed before the
| file itself is removed

ah ok, if you do
"ln foo foo.old && mv foo.new foo && chmod -s foo.old && rm foo.old",
that works too.

 -- erno