An apparently little known fact about dpkg is that it clears suid bits when upgrading packages. This defeats the hardlink-a-suid-binary-and-wait-for-exploit attack that used to be a worry, and which apparently still is to some.
joey@gnu:~>ln /usr/bin/sudo
joey@gnu:~>dir sudo
-rwsr-xr-x 3 root root 112K Jul 6 2008 sudo*
joey@gnu:~>sudo apt-get --reinstall install sudo
Reading package lists... Done
[...]
Get:1 http://ftp.egr.msu.edu unstable/main sudo 1.6.9p17-1 [177kB]
Fetched 177kB in 1s (91.0kB/s)
Created commit e5523fe: saving uncommitted changes in /etc prior to apt run
1 files changed, 14 insertions(+), 0 deletions(-)
(Reading database ... 167780 files and directories currently installed.)
Preparing to replace sudo 1.6.9p17-1 (using .../sudo_1.6.9p17-1_i386.deb) ...
Unpacking replacement sudo ...
Processing triggers for man-db ...
Setting up sudo (1.6.9p17-1) ...
joey@gnu:~>dir sudo
-rw------- 1 root root 112K Jul 6 2008 sudo
dpkg has done this since version 1.10.18.1, released in 2004.
PS, Can any rpm users tell me if rpm does this?
PPS, If you find yourself making statements like "While noexec is only a weak defense, it gives a little bit more protection", you are probably not really talking about security, but instead about a warm fuzzy feeling.
PPS, If shellcode can create a suid root executable, it can create it in
/root or some other directory that is not mounted nosuid.
On my sid box:
% ls -l /usr/bin/sudo -rwsr-xr-x 2 root root 127080 2008-07-06 00:37 /usr/bin/sudo % sudo apt-get --reinstall install sudo Reading package lists... Done Building dependency tree
Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 0B/187kB of archives. After this operation, 0B of additional disk space will be used. Do you want to continue [Y/n]? (Reading database ... 128253 files and directories currently installed.) Preparing to replace sudo 1.6.9p17-1 (using .../sudo_1.6.9p17-1_amd64.deb) ... Unpacking replacement sudo ... Processing triggers for man-db ... Setting up sudo (1.6.9p17-1) ... % ls -l /usr/bin/sudo -rwsr-xr-x 2 root root 127080 2008-07-06 00:37 /usr/bin/sudo
What am I missing?
You're missing that Joey's performing an ls on ~/sudo -- initially a hardlink to /usr/bin/sudo. Reinstalling the sudo package replaces /usr/bin/sudo in such a way that the hardlinked copy loses its suid bits:
AFAIK, dpkg-statoverride does not prevent the suid bit clearing from being done by dpkg. If it does, we've got a problem.
triplehelix: Of course /usr/bin/sudo remains suid over upgrade as you show. A hard link to that file, however, will not.
Doesn't look like rpm does it:
This is CentOS 5, so possibly not the latest version of rpm. Still should be fairly up-to-date though.