>On Fri, Jan 26, 2007 at 06:46:36AM -0500, Thor Lancelot Simon wrote:
>>On Thu, Jan 25, 2007 at 09:07:27PM +0100, Pavel Cahyna wrote:
>>> 
>>> Could nullfs encrypt the filehandles of the underlying filesystem and use
>>> those encrypted filehandles for NFS?
>>
>>What should actually happen is what e.g. Solaris does: the filehandle
>>given to the client should *always* be generated from the exported
>>directory and underlying filesystem specific data, rather than the
>>underlying data alone.  This would allow export of arbitrary directories
>>with different permissions.
>>
If I understand what you are suggesting, it can result in multiple file
handles/file when there are multiple hard links to a file. Although this
seems to be permitted for NFSv3 and NFSv4.0, it causes problems for clients.
(See a recent thread titled "RE: Finding Hardlinks" in the email archive
 at www.nfsv4.org.) They are going to try and "fix" the problem for NFSv4.1.

If you avoid having multiple handles/file, you can encrypt the filehandle,
but that still doesn't provide a lot of security, since a "bad guy" can
simply replay the filehandle. Since filehandles are T stable (ie. valid for
a very long time), they can't be expired and so replay becomes a no brainer.

> But this whole thread makes me think a security advisory and man
> page update is in order. if we have in exports
> 
> /usr/local/pub/sandbox -rw
> 
> and the /usr partition is a single filesystem. remote clients
> have rw for anything in /usr --- that's my current understanding,
> and I don't think this is apparent to most admins. When we export
> directories with NFS, we are exposing the _entire_filesystem_ via
> rpc, not just the directory specified in exports (even though
> brute force is required to rw files outside sandbox).

The mountd won't respond to a mount request for /usr unless "alldirs" was
specified, but it is true that a "bad guy" could guess/replay a file handle
for /usr and go from there. The exports(5) man page refers to local file
systems, but you can always improve man pages.

To hang export options off every i-node would be possible, but a PITA for what
I'd say is little gain. Until you go to RPCSEC_GSS, about all you can do is
restrict exports to "trusted hosts". (Here my production NFS servers don't
even have routes to anything but the two subnets my clients live on.)

Just mho, rick
ps: I'm assuming NetBSD is still compatible with ole 4.4. If not, then
    ignore most of what I said:-)