Messages in this thread | | | Date | Thu, 2 Dec 1999 20:13:47 -0500 (EST) | From | Alexander Viro <> | Subject | Re: Can't hardlink in different dirs. (BUG#826) |
| |
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> On Thu, 2 Dec 1999, Alexander Viro wrote: > > >Don't bring the policy question into the kernel. If you want to kill the > >contents of inode - unlink() is _not_ a way to go. truncate() is. > > What have unlink() or truncate() to do with this issue? The only system > call we are talking about is _link_(2). > > Even supposing you can undo after 1 pico second the effect of the link(2), > for one pico second the system stayed in a state I don't like.
Excuse me? I'm saying that you can emulate link() with open(). And the workaround being the same - cat /dev/null > file_to_delete. Look: a) if you have file visible to attacker - he doesn't need link(), he can use the original reference until you remove it. b) if you are removing the reference, but not the contents - you are unsafe even if attacker didn't call link() at all. He might say exec 17<file_you_were_going_to_delete and use /dev/fd/17 afterwards. c) taking system single-user is slightly more drastic measure than using cat. So even the "oh, I'll drop to single-user/reboot and his processes will go away" doesn't cut it - it's _massive_ overkill. And if you can do that - you have root and if there are extra links to the file you'ld better (1) truncate it anyway, (2) spend a couple of minutes to find other links, (3) look around in the attacker directories - he may have more interesting things there and (4) LART the kiddie _hard_.
Again, until you've removed your link _other_ links do not matter. And once you've removed it it will not be used to create new ones anyway. I still don't see anything you could buy prohibiting link().
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |