Boyd Stephen Smith Jr. wrote:
Did you mean this to go to the list? I've replied directly to you, but feel free to repost my mail or part thereof to the list if you believe the discussion could continue there.
Sorry, my fault.
On Friday 2009 January 16 13:03:53 you wrote:Boyd Stephen Smith Jr. wrote:What about hardlinking the suid-root binaries to a hidden location, waiting for a security hole to be found/fixed, and then running the old binary to exploit the hole? Does dpkg handle suid/sgid files so that this is prevented?Against hard linking attacks, as You described, it is recommended to have user-writable directories (usually /home and /tmp) on separate filesystems (since hard linking only works within one filesystem). These filesystems should be mounted with nosuid and nodev options. Nosuid protects against exploiting of vulnerable suid/sgid binaries, while nodev denies access to probably exploitable kernel code (i.e. device drivers). The only remaining vulnerability is through an exploitable syscall. Also it is recommended to make use of noexec on filesystems containing data only (e.g. /var/log, /var/mail) and ro for filesystems containing application binaries (e.g. /usr). That makes it a bit inconvenient to upgrade applications, since you have to remount /usr with rw before and with ro after doing the upgrade.Is this documented somewhere? I can understand Debian not doing this partitioning by default, but it should be easily accessible to those that want to "harden" their systems. It would also be nice to see what no$feature/ro options Debian supports for various filesystems.
Search for the Securing Debian Manual and see: http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.2This manual describes a lot of security improvements for Debian installation. You probably does not need them all, however, its a nice guide to Unix/Linux security.
At least once, I had a nodev /home bite me. Of course, I really shouldn't be building chroots in home, but it was the filesystem with the most space at the time.On inode filesystems a file is removed when the link counter gets zero and the file is not open. When you open a file and unlink it, the file will be kept till it is open.The dpkg tool, and no other package manager, does not, can not, however, it is not intended to prevent hard linking of suid/sgid binaries.It certainly could mitigate the risk by intentionally writing zeros to the inode(s) containing removed suid binaries. This does not require raw-writing the disk or having non-working binaries for any period of time either. IIRC, Gentoo provided such a feature at some point. I could see dpkg handling it by hardlinking any suid binaries that are "to be replaced" or "to be removed" before doing a remove/upgrade/install normally and then writing zeros to the saved file before unlinking it. If broken binaries can be accepted for some period of time, they can simply be overwritten with zeros before the normal remove/upgrade/install process.
To overwrite a file before it is upgraded is _very_ dangerous. What if the upgrade won't work? Then you probably lost your libc, or something? Therefore, the safe way for an upgrade is to create create the new file with an temporary name, and when it is ready, copy it with a single move operation over the original.
Imagine the following. A server (e.g. apache or sshd) is running and using a certain library. The library is opened and is read from time to time. If you overwrite this file with zeros, your server crashes. If you let him use the obsolete library till its upgrade is finished, then force it to restart, the service can have a downtime of less than a second.