Thu, Jan 18, 2007 at 12:51:24PM +0100, Hauke Fath wrote:
Am 17.01.2007 um 21:43 Uhr -0500 schrieb George Georgalis:
>I'm having trouble writing an /etc/exports file for
>a read-only mount point. I'd expect it something
>like:
>
>/host/software -maproot=nobody:nobody -ro -network 10/8
>
>but on the target host, that yeilds
>
>mount_nfs: can't access /host/software: Permission denied
>
>while other rw /host/* exports mount fine. What exactly is
>the syntax for a ro export?

Let me guess: The /host/* exports are on the same filesystem?

You cannot export directories from one filesystem with differing
credentials (like rw/ro, different access control liste, etc.). A
workaround is to use null mounts, and export those.

The problem with doing this is that you don't really gain much. Maybe we
should just turn off the restructions we have.

The problem is that the NFS server code can't tell if a file handle
corresponds to a file under a given mount point or not when you have
multiple exposed mount points in one file system. So say you had one
directory in an fs exposed read-write and another read-only. If an
attacker took a file handle from the r/o mount and used it via the r/w
mount point, the corresponding file can be modified even though the
initial layout would say it wouldn't.

Null mounts don't change this as the file-system-specific part of our file
handles are the same between a null mount and the underlying file system.
So given a file handle from the null mount, you can figure out the file
handle for the same file for the non-nullfs fs.

Perhaps the solution is to make the code be VERY clear that we will permit
you to have differing export ability but that the laxest restrictions
apply to the whole file system. As in we have the kernel remember the
laxest permissions on an export and if you add an additional export that
makes the permissions laxer, we emit a kernel warning message. Hmmm
We also probably want to track the tightest too. So if you have a mount
exported r/o and add a r/w mount, or if you have a r/w mount and add a r/o
mount, the kernel mentions that your file system security may not be what
you expect. Adding a second such mount shouldn't emit a message, though.

Thoughts?

Take care,

Bill

PGP SIGNATURE
Version: GnuPG v1.4.3 (NetBSD)

MaR4lBatzWPExYmI7/dySuQ=
=zaln
PGP SIGNATURE

Thu, Jan 25, 2007 at 09:17:16AM -0800, Bill Studenmund wrote:
The problem is that the NFS server code can't tell if a file handle
corresponds to a file under a given mount point or not when you have
multiple exposed mount points in one file system. So say you had one
directory in an fs exposed read-write and another read-only. If an
attacker took a file handle from the r/o mount and used it via the r/w
mount point, the corresponding file can be modified even though the
initial layout would say it wouldn't.

Null mounts don't change this as the file-system-specific part of our file
handles are the same between a null mount and the underlying file system.
So given a file handle from the null mount, you can figure out the file
handle for the same file for the non-nullfs fs.

Could nullfs encrypt the filehandles of the underlying filesystem and use
those encrypted filehandles for NFS?

Pavel Cahyna

Pavel Cahyna skrev:
Thu, Jan 25, 2007 at 09:17:16AM -0800, Bill Studenmund wrote:
>The problem is that the NFS server code can't tell if a file handle
>corresponds to a file under a given mount point or not when you have
>multiple exposed mount points in one file system. So say you had one
>directory in an fs exposed read-write and another read-only. If an
>attacker took a file handle from the r/o mount and used it via the r/w
>mount point, the corresponding file can be modified even though the
>initial layout would say it wouldn't.
>>
>Null mounts don't change this as the file-system-specific part of our file
>handles are the same between a null mount and the underlying file system.
>So given a file handle from the null mount, you can figure out the file
>handle for the same file for the non-nullfs fs.

Could nullfs encrypt the filehandles of the underlying filesystem and use
those encrypted filehandles for NFS?

Who cares? All you're doing is preventing users from having an easy way
to find the file handle for a file. If someone really wants to, they can
just brute-force it. The underlying problem is that the files are
accessible r/w, even though you wanted them exposed r/o.
There is no easy way around that problem.

Johnny

Sat, Jan 27, 2007 at 11:17:54AM +0100, Edgar Fu? wrote:
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
I usually work around this (I hope!) by putting a null mount in between.
E.g. null-mount /usr/local/pub/sandbox to /export/sandbox and NFS-export that.
I hope I'm correct to believe that the filesystem the export is now limited to
is /export/sandbox in that case.

It is and it isn't.

There are two ways to attach an NFS exported file system for what we're
discussing.

The first is to grab a file handle and issue lookups on "" syntheticly,
and to walk above the restricted exported mount point.

That method will fail here, though I'm not fully sure how it will fail.
When the walk, through the null mount, got to the root of the exported
nullfs, all of the lookup routines will notice that they are at the root
of a file system. I expect they will fail.

However if the attacker instead knows enough information about the
underlying file system to be able to synthesize a file handle for the
underlying fs, this mount restriction won't protect you. Given the
underlying file handle, the nullfs file handle can be directly generated.
That's how we make file handles now. :-)

So someone can wander around the whole file system in the export.

However someone really has to know what's going on to do this, and if you
did the random generation # step at mkfs, then it's not an easy thing to
do.

So you closed some doors but not others.

The problem is that it's not easy to close this door with the current NFS
structure.

Take care,

Bill

PGP SIGNATURE
Version: GnuPG v1.4.3 (NetBSD)

ZcQWBMMIxVX/evBWeuSyzEc=
=cQsb
PGP SIGNATURE

Sat, Jan 27, 2007 at 11:17:54AM +0100, Edgar Fu? wrote:
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
I usually work around this (I hope!) by putting a null mount in between.
E.g. null-mount /usr/local/pub/sandbox to /export/sandbox and NFS-export that.
I hope I'm correct to believe that the filesystem the export is now limited to
is /export/sandbox in that case.

It is and it isn't.

There are two ways to attach an NFS exported file system for what we're
discussing.

The first is to grab a file handle and issue lookups on "" syntheticly,
and to walk above the restricted exported mount point.

That method will fail here, though I'm not fully sure how it will fail.
When the walk, through the null mount, got to the root of the exported
nullfs, all of the lookup routines will notice that they are at the root
of a file system. I expect they will fail.

However if the attacker instead knows enough information about the
underlying file system to be able to synthesize a file handle for the
underlying fs, this mount restriction won't protect you. Given the
underlying file handle, the nullfs file handle can be directly generated.
That's how we make file handles now. :-)

So someone can wander around the whole file system in the export.

However someone really has to know what's going on to do this, and if you
did the random generation # step at mkfs, then it's not an easy thing to
do.

So you closed some doors but not others.

The problem is that it's not easy to close this door with the current NFS
structure.

Take care,

Bill

PGP SIGNATURE
Version: GnuPG v1.4.3 (NetBSD)

ZcQWBMMIxVX/evBWeuSyzEc=
=cQsb
PGP SIGNATURE