Subject: Re: exporting -ro nfs
To: None <tech-security@netbsd.org>
From: Travis H. <travis+ml-tech-security-netbsd@subspacefield.org>
List: tech-security
Date: 02/27/2007 01:55:09
--qSHHer9gQ0dtepKr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 29, 2007 at 02:28:04PM -0500, rick@snowhite.cis.uoguelph.ca wro=
te:
> You can certainly encrypt/decrypt file handles in the server, but all that
> does is make it harder to spoof a file handle.   It doesn't stop a client
> from doing a [...] replay attack using file handles captured on
> the wire.

If the encryption/decryption key is dependent on the client then
handles for one client wouldn't be valid for another.  I don't think
they should be, for the simple reason it enables their theft.  From
a network security perspective, protection between users on the same
network node is a host security issue.

Personally I think the idea of using server inode numbers in any sort
of network traffic is a very bad sign, and the notion that a NFS
client can open an inode and hold it open indefinitely is spooky.  The
inode randomization, if not automatic, is too arcane to rely upon for
security, and renumbering is very costly; surely it's better to have
some sort of intermediate credential that could be revoked?

> Personally, I don't think it gets you enough to be worth the
> overhead of the encryption/decryption, but???

Computers are fast, and getting faster.  Crypto is cheap.  We have
enough fast, unsecure systems.
--=20
Good code works.  Great code can't fail. -><-
<URL:http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email john@subspacefield.org.

--qSHHer9gQ0dtepKr
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (OpenBSD)

iQIVAwUBRePj3WQVZZEDJt9HAQKiYw//UqiDVaKWBmg46uLedcjFExf032bUlFbu
Ujt4O5dvYSBzRs8csUVM4Q7fC5cHT/nFs/KLL/yucyxgrUM+ZThB+meZCLsJHd6J
pRZi1ZSFxuIPmzzHChI9w63zILkudUQmSyp1J/AELZIkiVfGI/CACPA2sCyPnS3M
dB0sTw8qB9HU3tq7iXcsregdn2ICa/58HeDVgkjx0bHdKFDY1UMzZoQPRxauP4+z
VXzksndsH9wGMaWEjASdmbGSa/W36jyS/RuQYdqEkVHCjUPXI1M/ERSxMiJel8cO
b8QN2Rj3D+R8pQUMCjK1chYChI0DCAMSMfJfS21AV0/abc0j5SjqUNIkeereqHft
JVtUWEACSgBH39I5SBNwUn7CH9gHFXam3S4Fpw8KQPvWcERZ7z7xjIpJ+VcfWtQ6
Wo47ufTtgt8Nw03OWbBQ4uhEDoBBDkSUTioVWR12skYSQtOycUc7R/7htsTgRpMz
oFwxvDwMQO/L51lALkPsA9cEx8X+U5z5yjGGrnzYp+yDaiW/gDW957j3pxZy/iXI
NVBBOhIMD44SXZOBdkYzEvVBZ3d4ImZQK3sQYrmolyKG4La9tl+oc3qpBezCzeK9
yQhFvLxeszBAmZgCuPZRwJRTIsXPb9eGK5EOl+M/E3vieoC4Q8GwqXeNCOZo0uz9
qbaYGvkqzW0=
=Tro5
-----END PGP SIGNATURE-----

--qSHHer9gQ0dtepKr--