Indeed. The main benefit of inode generation numbers is in detecting
stale file handles across inode deletion/reuse.
And I remember that fsirand wasn't (or isn't?) really that random
either. One of the very first NFS hacks I saw was Leendert van Doorns
nfsbug thing that guessed SunOS file handles, exploiting a weakness
in their fsirand implementation. You can't produce good random numbers
fast, which is what fsirand would have to.
Concerning randomizing file handles for security reasons, I have
experimented with something like this in an early knfsd implementation.
The idea was for the NFS server to have a secret byte string S(X) per
client X, and for each file handle passed to client X to compute a
keyed MD5 or SHA that is put in the file handle:
+-----------+
| dev, ino | --> concatenated with S(X)
| etc | |
+-----------+ MD5 or SHA
| keyed | |
| hash | <----------------/
+-----------+
While the top part of the FH is constant for a file, the bottom part
differs between clients. This means that even if an attacker on host X
correctly guesses inode, device etc (inode #2 and one out of ~64 devices
is quite a small search space), he still won't know the random part of
the handle.
The obvious disadvantage of this approach is that you need a fairly
large file handle cache on the server, otherwise you'll slow things
down quite a bit. Second, it doesn't help you a bit if the attacker
can snoop your traffic. Thus, there are but a few situations where this
really buys you additional security, e.g. when exporting one directory
readonly to the world, and giving certain machines write access to that
directory. With ordinary FHs, an attacker could obtain file handles by
legal means, and spoof the source IP to do evil things. Randomizing
file handles based on the client identity protects you from this kind
of attack.
However, most of the time you'd be way better off packet filtering
source spoofed packets, or by using a decent authentication scheme
(if only we had one).
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
-
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/