Messages in this thread | | | Date | Thu, 2 Dec 1999 13:34:31 -0500 (EST) | From | Alexander Viro <> | Subject | Re: Can't hardlink in different dirs. (BUG#826) |
| |
On Thu, 2 Dec 1999, Peter J. Braam wrote:
> > Effectively open does the same wrt keeping file alive. So? > > I have said nothing about open - just about link.
... and anything that relies on unlink() as mechanism to remove the file contents is broken, so prohibiting link() alone will not change _anything_ security-wise. If you can kill processes of potential attacker you can remove his links too. Moreover, there is a standard way to remove the file contents and it's _not_ unlink(). It's cat /dev/null>foo (==truncate()).
Again, unlink() was never supposed to remove the file. None of the Unices provide such semantics. So if somebody relies on that - he will lose. Big way. Proposed change does not fix any security holes, it only gives false sense of security. If you have a hostile environment and blindly rely on rm to remove a file - you have a security problem on hands.
> > Aegis - maybe. Linux in general? IMNSHO it seriously breaks normal UNIX > > semantics. > > OK, how serious? Does it outweigh the benefits.
What benefits? OK, we did that change. You have a suid binary foo and it's broken. You are saying rm foo, just to discover local cracker abusing foo two hours later. It is supposed to be a benefit?
The same applies to quota abuse. And unlike the link(), this scenario doesn't rely on access to the same filesystem. If somebody wants to play such games link() is the least of your problems - it's effect can be completely reproduced with plain open(). exec 42</bar/foo and several hours after that sh -c /dev/fd/42 will do the trick - fork() preserves open descriptors.
- 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/
| |