Re: basically security of linux
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
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
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:
This 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
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
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.