[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: basically security of linux

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:

Reading there and clicking through a bit I find this:
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.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: