On Friday 2009 January 16 15:49:46 Repasi Tibor wrote: >Boyd Stephen Smith Jr. wrote: >> 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). >> Is this documented somewhere? >Search for the Securing Debian Manual and see: >http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.2
Reading there and clicking through a bit I find this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225692 which indicates that dpkg does, in fact, take active steps to prevent the hardlinking attacks I described. That is good to know. >> 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. 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. > >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. Okay, I know that, and I didn't suggest doing anything to a file that had 0 link count. >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. Which is why my primary option had no period of time when the file at path /suid/binary/needed/by/upgrade_process had (a) bad content, (b) missing executable bit, or (c) missing suid bit. Turns out if I read just a little bit more, I wouldn't have wasted so much bandwidth. Sorry, guys. Big thanks to all the DDs that fix my problems before I think about them. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
