nfs root directory security

nfs root directory security

[Scott Leerssen]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

Attached is a patch for nfs-utils-1.0.1-2.9 (RedHat) that adds a bit of
security and ease of use for exported filesystems that have lots of
users in lots of subdirectories.

What it does is disallow nfs clients from mounting a directory that is
marked execute only (chmod 0111), controlled by an option
"root_mnt_orig".  This is handy if one has a constantly changing
hierarchy of subdirectories where the client is the only one who knows
where to look for his stuff.  Consider a directory structure that looks
like:

/A/B/C/123
/A/B/C/456
/A/B/C/789

If A, B and C are mode 0111, the nfs client must directly mount 123,
456, or 789.  OK, this is a kind of lame example, but one can easily add
some obscurity to the directory structure under /A and see how
effectively this hides NFS mount points and adds some ease of use when
maintaining a TON of mount points.

Enjoy, and feel free to come up with an option name that doesn't suck.

-- 
Scott Leerssen <scott@leerssen.com>

[-- Attachment #2: nfs-utils-1.0.1.mnt-root-orig.patch --]
[-- Type: text/x-patch, Size: 2169 bytes --]

diff -uNr nfs-utils-1.0.1/support/include/nfs/export.h nfs-utils-1.0.1.mnt-root-orig.patch/support/include/nfs/export.h
--- nfs-utils-1.0.1/support/include/nfs/export.h	Wed Feb 27 20:37:44 2002
+++ nfs-utils-1.0.1.mnt-root-orig.patch/support/include/nfs/export.h	Tue Jun 17 13:09:11 2003
@@ -24,6 +24,7 @@
 #define NFSEXP_NOSUBTREECHECK	0x0400
 #define NFSEXP_NOAUTHNLM	0x0800
 #define NFSEXP_FSID		0x2000
+#define NFSEXP_ROOTMNTORIG	0x4000
 #define NFSEXP_ALLFLAGS		0x3FFF
 
 #endif /* _NSF_EXPORT_H */
diff -uNr nfs-utils-1.0.1/support/nfs/exports.c nfs-utils-1.0.1.mnt-root-orig.patch/support/nfs/exports.c
--- nfs-utils-1.0.1/support/nfs/exports.c	Wed May 29 02:07:43 2002
+++ nfs-utils-1.0.1.mnt-root-orig.patch/support/nfs/exports.c	Tue Jun 17 13:12:15 2003
@@ -176,6 +176,8 @@
 		"no_" : "");
 	fprintf(fp, "%ssecure_locks,", (ep->e_flags & NFSEXP_NOAUTHNLM)?
 		"in" : "");
+	fprintf(fp, "%sroot_mnt_orig,", (ep->e_flags & NFSEXP_ROOTMNTORIG)?
+		"" : "no_");
 	if (ep->e_flags & NFSEXP_FSID) {
 		fprintf(fp, "fsid=%d,", ep->e_fsid);
 	}
@@ -346,6 +348,10 @@
 			ep->e_flags |= NFSEXP_ALLSQUASH;
 		else if (strcmp(opt, "no_all_squash") == 0)
 			ep->e_flags &= ~NFSEXP_ALLSQUASH;
+		else if (strcmp(opt, "root_mnt_orig") == 0)
+			ep->e_flags |= NFSEXP_ROOTMNTORIG;
+		else if (!strcmp(opt, "no_root_mnt_orig"))
+			ep->e_flags &= ~NFSEXP_ROOTMNTORIG;
 		else if (strcmp(opt, "subtree_check") == 0)
 			ep->e_flags &= ~NFSEXP_NOSUBTREECHECK;
 		else if (strcmp(opt, "no_subtree_check") == 0)
diff -uNr nfs-utils-1.0.1/utils/mountd/mountd.c nfs-utils-1.0.1.mnt-root-orig.patch/utils/mountd/mountd.c
--- nfs-utils-1.0.1/utils/mountd/mountd.c	Tue Jun 17 13:02:39 2003
+++ nfs-utils-1.0.1.mnt-root-orig.patch/utils/mountd/mountd.c	Tue Jun 17 13:14:42 2003
@@ -264,6 +264,10 @@
 	} else if (!S_ISDIR(stb.st_mode) && !S_ISREG(stb.st_mode)) {
 		xlog(L_WARNING, "%s is not a directory or regular file", p);
 		*error = NFSERR_NOTDIR;
+	} else if ((((S_IRUSR|S_IRGRP|S_IROTH) & stb.st_mode) == 0) &&
+			((exp->m_export.e_flags & NFSEXP_ROOTMNTORIG) == 0)) {
+		xlog(L_WARNING, "%s not readable", p);
+		*error = NFSERR_ACCES;
 	} else {
 		struct nfs_fh_len  *fh;
 

Re: nfs root directory security

[Neil Brown]

On  June 17, scott@leerssen.com wrote:
> Attached is a patch for nfs-utils-1.0.1-2.9 (RedHat) that adds a bit of
> security and ease of use for exported filesystems that have lots of
> users in lots of subdirectories.
> 
> What it does is disallow nfs clients from mounting a directory that is
> marked execute only (chmod 0111), controlled by an option
> "root_mnt_orig".  This is handy if one has a constantly changing
> hierarchy of subdirectories where the client is the only one who knows
> where to look for his stuff.  Consider a directory structure that looks
> like:
> 
> /A/B/C/123
> /A/B/C/456
> /A/B/C/789
> 
> If A, B and C are mode 0111, the nfs client must directly mount 123,
> 456, or 789.  OK, this is a kind of lame example, but one can easily add
> some obscurity to the directory structure under /A and see how
> effectively this hides NFS mount points and adds some ease of use when
> maintaining a TON of mount points.

Hi.
I'm cannot see how this adds any significant security.

If you only want the client to mount certain bits, and the clients
know which bits to mount, then just mount those bits on the client.

Given that you allow the clients to mount any directories that they
have read access to, how does it hurt to allow them to mount parents
that they don't have read access to?
I can see that you don't want them to, but surely that is a client
configuration issue, not a server issue.

NeilBrown


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs root directory security

[Scott Leerssen]

On Tue, 2003-06-17 at 19:36, Neil Brown wrote:
> On  June 17, scott@leerssen.com wrote:
> > Attached is a patch for nfs-utils-1.0.1-2.9 (RedHat) that adds a bit of
> > security and ease of use for exported filesystems that have lots of
> > users in lots of subdirectories.
> > 
> > What it does is disallow nfs clients from mounting a directory that is
> > marked execute only (chmod 0111), controlled by an option
> > "root_mnt_orig".  This is handy if one has a constantly changing
> > hierarchy of subdirectories where the client is the only one who knows
> > where to look for his stuff.  Consider a directory structure that looks
> > like:
> > 
> > /A/B/C/123
> > /A/B/C/456
> > /A/B/C/789
> > 
> > If A, B and C are mode 0111, the nfs client must directly mount 123,
> > 456, or 789.  OK, this is a kind of lame example, but one can easily add
> > some obscurity to the directory structure under /A and see how
> > effectively this hides NFS mount points and adds some ease of use when
> > maintaining a TON of mount points.
> 
> Hi.
> I'm cannot see how this adds any significant security.
> 
> If you only want the client to mount certain bits, and the clients
> know which bits to mount, then just mount those bits on the client.
> 
> Given that you allow the clients to mount any directories that they
> have read access to, how does it hurt to allow them to mount parents
> that they don't have read access to?
> I can see that you don't want them to, but surely that is a client
> configuration issue, not a server issue.

Here's a specific example.  Let's say you have a data center and use
network attached storage to maintain filesystems for all of your
customers.  Since all customers have access to the NAS, and all have
their own box with root access, it's not too difficult to go poking
around on the NAS to find other folks' stuff.  One obvious way to deal
with this is to have separate exported filesystems for each customer,
however, that becomes a huge maintenance hassle if you have a few
hundred customers.  This feature allows you to maintain all the
filesystems under one NFS root, while hiding the filesystems of other
customers.


-- 
Scott Leerssen <scott@leerssen.com>



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs root directory security

[Neil Brown]

On  June 17, scott@leerssen.com wrote:
> 
> Here's a specific example.  Let's say you have a data center and use
> network attached storage to maintain filesystems for all of your
> customers.  Since all customers have access to the NAS, and all have
> their own box with root access, it's not too difficult to go poking
> around on the NAS to find other folks' stuff.  One obvious way to deal
> with this is to have separate exported filesystems for each customer,
> however, that becomes a huge maintenance hassle if you have a few
> hundred customers.  This feature allows you to maintain all the
> filesystems under one NFS root, while hiding the filesystems of other
> customers.


So you want to hide the names from people who don't know them.
Sure removing read permission is enough. Without read permission you
cannot "ls" and so cannot find the names.

Alternately just export the subdirectories rather than the parent.
Export different subdirectories to different clients.

NeilBrown


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs root directory security

[Scott Leerssen]

On Tue, 2003-06-17 at 23:47, Neil Brown wrote:
> On  June 17, scott@leerssen.com wrote:
> > 
> > Here's a specific example.  Let's say you have a data center and use
> > network attached storage to maintain filesystems for all of your
> > customers.  Since all customers have access to the NAS, and all have
> > their own box with root access, it's not too difficult to go poking
> > around on the NAS to find other folks' stuff.  One obvious way to deal
> > with this is to have separate exported filesystems for each customer,
> > however, that becomes a huge maintenance hassle if you have a few
> > hundred customers.  This feature allows you to maintain all the
> > filesystems under one NFS root, while hiding the filesystems of other
> > customers.
> 
> 
> So you want to hide the names from people who don't know them.
> Sure removing read permission is enough. Without read permission you
> cannot "ls" and so cannot find the names.

The point is that there's nothing stopping the client from them from
mounting the directory.  The current NFS implementation permits it, and
it's a lot easier to catch someone repeatedly attempting to find mount
points than it is to find someone who just attempts to cd into a
directory below something that they have mount access to.

> 
> Alternately just export the subdirectories rather than the parent.
> Export different subdirectories to different clients.
> 

Try maintaining that for a few hundred (heck even a few dozen) clients.

-- 
Scott Leerssen <scott@leerssen.com>



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs root directory security

[Bogdan Costescu]

On Wed, 18 Jun 2003, Neil Brown wrote:

> So you want to hide the names from people who don't know them.

Security through obscurity rarely works...

> Alternately just export the subdirectories rather than the parent.
> Export different subdirectories to different clients.

I think that this is the only solution that makes sense. Obviously you 
need a script to take care of the /etc/exports file and upon any 
modification run the 'exportfs' command. But you do this already, don't 
you ? Or you maintain the hundreds or thousands client directories by 
hand ???
The fact the the clients know what priviledges they have and can change 
permissions sounds very strange to me from a security point of view...

-- 
Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs root directory security

[Scott Leerssen]

On Wed, 2003-06-18 at 05:30, Bogdan Costescu wrote:
> On Wed, 18 Jun 2003, Neil Brown wrote:
> 
> > So you want to hide the names from people who don't know them.
> 
> Security through obscurity rarely works...

Which is why we want NFS to stop a client from mounting anything above
the FS that it is supposed to have.

> 
> > Alternately just export the subdirectories rather than the parent.
> > Export different subdirectories to different clients.
> 
> I think that this is the only solution that makes sense. 

It's a function of how many, and often the mount points and the
addresses to which the mount points belong change.  Not to mention it's
pretty easy to spoof NFS by aliasing an interface to another address; if
you have your root mounted in /A/B/C/foo, then the curious will attempt
to mount /A/B/C to see what else is hanging around.

> Obviously you 
> need a script to take care of the /etc/exports file and upon any 
> modification run the 'exportfs' command. But you do this already, don't 
> you ? Or you maintain the hundreds or thousands client directories by 
> hand ???

It's automatic.

The first mount point, the root FS, is given to the client via DHCP. 
The client's fstab has been automatically populated by management
software to point to other stuff that it needs from the NAS, so when the
client boots, it mounts the FS that it has been given, plus any
additional FS that it wants/needs.

> The fact the the clients know what priviledges they have and can change 
> permissions sounds very strange to me from a security point of view...

The clients shouldn't be able to change anything, or get to anything
they are not supposed to.

Sorry... I didn't want to "advertise", as I think it's lame, but some
more context is required for this to make sense...  Take a look at
www.racemi.com, which is where I work and the reason for this simple and
quite effective change.  When combined with the other security features
of NFS, vlans, and smart switches, this gets us what we want to convince
customers that their filesystems are safe on shared storage.

For what it's worth, SunOS and BSD don't prevent mount access to
read-restricted directories either, so we had to tweak them as well for
those who desire slower NFS servers :)

-- 
Scott Leerssen <scott@leerssen.com>



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs root directory security

[Bogdan Costescu]

On 18 Jun 2003, Scott Leerssen wrote:

> Which is why we want NFS to stop a client from mounting anything above
> the FS that it is supposed to have.

Yes, but isn't this achieved through lines like:

/home/client1	*.client1.com(rw)

If you want to export /home, you still have to specify all 
domains/clients, like in:

/home	*.client.com(rw),*.client2.com(rw),*.client3.com(rw)

so there is not so much more work to do. Unless you use a wildcard like:

/home	*(rw)

which I certainly don't find secure.

> Not to mention it's pretty easy to spoof NFS by aliasing an interface to
> another address;

That's why it's not advisable to use NFS on anything that you don't 
control. For example, one easily overlooked security problem is having two 
users with same UID on different systems - or allowing a computer not 
controlled by you to mount such an export; the admin of this computer can 
create users at will and be able to access your files...
If you worry about aliasing of interfaces, you should look into statical
ARP entries and/or netfilter.

> if you have your root mounted in /A/B/C/foo, then the curious will
> attempt to mount /A/B/C to see what else is hanging around.

And that's where exporting per client will secure it: the client is not 
allowed by the server to mount /A/B/C.

> The first mount point, the root FS, is given to the client via DHCP. 

The client can be given /A/B/C/123 instead of /A/B/C by the same automated 
procedure. We do this here on our clusters (using PXELinux):

  append root=/dev/nfs nfsroot=192.168.7.203:/clients/%s ip=dhcp

However, because this is a closed network on which I have total control, I 
have it exported like:

/clients	192.168.7.0/24(rw,no_root_squash)

where /clients contains directories called 192.168.7.1, 192.168.7.2, etc.

-- 
Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs root directory security

[Scott Leerssen]

On Wed, 2003-06-18 at 09:55, Bogdan Costescu wrote:
> On 18 Jun 2003, Scott Leerssen wrote:
> 
> > Which is why we want NFS to stop a client from mounting anything above
> > the FS that it is supposed to have.
> 
> Yes, but isn't this achieved through lines like:
> 
> /home/client1	*.client1.com(rw)
> 
> If you want to export /home, you still have to specify all 
> domains/clients, like in:
> 
> /home	*.client.com(rw),*.client2.com(rw),*.client3.com(rw)
> 
> so there is not so much more work to do. Unless you use a wildcard like:
> 
> /home	*(rw)
> 
> which I certainly don't find secure.
> 
> > Not to mention it's pretty easy to spoof NFS by aliasing an interface to
> > another address;
> 
> That's why it's not advisable to use NFS on anything that you don't 
> control. For example, one easily overlooked security problem is having two 
> users with same UID on different systems - or allowing a computer not 
> controlled by you to mount such an export; the admin of this computer can 
> create users at will and be able to access your files...
> If you worry about aliasing of interfaces, you should look into statical
> ARP entries and/or netfilter.
> 
> > if you have your root mounted in /A/B/C/foo, then the curious will
> > attempt to mount /A/B/C to see what else is hanging around.
> 
> And that's where exporting per client will secure it: the client is not 
> allowed by the server to mount /A/B/C.
> 
> > The first mount point, the root FS, is given to the client via DHCP. 
> 
> The client can be given /A/B/C/123 instead of /A/B/C by the same automated 
> procedure. We do this here on our clusters (using PXELinux):
> 
>   append root=/dev/nfs nfsroot=192.168.7.203:/clients/%s ip=dhcp
> 
> However, because this is a closed network on which I have total control, I 
> have it exported like:
> 
> /clients	192.168.7.0/24(rw,no_root_squash)
> 
> where /clients contains directories called 192.168.7.1, 192.168.7.2, etc.

I agree with everything you say here, and in a controlled and fairly
unchanging environment with clients you trust, exporting to specific
clients is a perfectly acceptable solution.  All I'm suggesting is
adding an extra "layer of the onion" by restricting the ability to mount
read-restricted directories.  It gives us the ability to create
mountable filesystems for each server in a path that can not be
traversed by mounting higher level directories.

Imagine if the B and C paths of /A/B/C/root are cryptographically
generated names, and that C is different for every mount point, B is
different for every "repository", and A is simply an anchor in the root
of my NAS.  I can export my clients root filesystems as:

   /A 192.168.100.0/255.255.255.0(rw,no_root_squash,...)

If B and C are unmountable and unguessable (without a lot of failed and
obvious nfs mount attempts), I don't have to worry about anyone but the
intended client mounting its root filesystem (assuming the network is
safe from sniffing DHCP and mount requests).  Plus, I don't have to have
an entry for every single client.  I could, and that would buy me an
added bit of assurance, but I don't need one so it's much easier to
maintain hundreds of mount points.

Of course, there's a lot more to securing an NFS environment such as
this, particularly when you can't trust the clients to behave.  This
tweak just eases the burden of managing exports for hundreds (or
thousands) of clients on as many NAS as you can imagine.  The burden is
shifted to managing unreadable pathnames in the management software...
(sigh).

That's about all I have to add on this... feel free to use the patch or,
if you haven't already, delete it from your inbox.

-- 
Scott Leerssen <scott@leerssen.com>



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs root directory security

[Frank Cusack]

On Wed, Jun 18, 2003 at 10:27:50AM -0400, Scott Leerssen wrote:
> I agree with everything you say here, and in a controlled and fairly
> unchanging environment with clients you trust, exporting to specific
> clients is a perfectly acceptable solution.

The only solution.

What you need to do is automate, not obfuscate.

/fc


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RE: nfs root directory security

[Heflin, Roger A.]

Scott,

If you really want to be scared, try=20
"showmount -a servername"
This will tell the server to list the clients and what filesystems they =
have
mounted.  And unguessable becomes a non-issue, and anyone can grab =
anyone
elses data since they know exactly what partition to mount.


		Roger

> -----Original Message-----
> From:	Scott Leerssen [SMTP:scott@leerssen.com]
> Sent:	Wednesday, June 18, 2003 9:28 AM
> To:	Bogdan Costescu
> Cc:	Neil Brown; nfs@lists.sourceforge.net
> Subject:	Re: [NFS] nfs root directory security
>=20
> I agree with everything you say here, and in a controlled and fairly
> unchanging environment with clients you trust, exporting to specific
> clients is a perfectly acceptable solution.  All I'm suggesting is
> adding an extra "layer of the onion" by restricting the ability to =
mount
> read-restricted directories.  It gives us the ability to create
> mountable filesystems for each server in a path that can not be
> traversed by mounting higher level directories.
>=20
> Imagine if the B and C paths of /A/B/C/root are cryptographically
> generated names, and that C is different for every mount point, B is
> different for every "repository", and A is simply an anchor in the =
root
> of my NAS.  I can export my clients root filesystems as:
>=20
>    /A 192.168.100.0/255.255.255.0(rw,no_root_squash,...)
>=20
> If B and C are unmountable and unguessable (without a lot of failed =
and
> obvious nfs mount attempts), I don't have to worry about anyone but =
the
> intended client mounting its root filesystem (assuming the network is
> safe from sniffing DHCP and mount requests).  Plus, I don't have to =
have
> an entry for every single client.  I could, and that would buy me an
> added bit of assurance, but I don't need one so it's much easier to
> maintain hundreds of mount points.
>=20
> Of course, there's a lot more to securing an NFS environment such as
> this, particularly when you can't trust the clients to behave.  This
> tweak just eases the burden of managing exports for hundreds (or
> thousands) of clients on as many NAS as you can imagine.  The burden =
is
> shifted to managing unreadable pathnames in the management software...
> (sigh).
>=20
> That's about all I have to add on this... feel free to use the patch =
or,
> if you haven't already, delete it from your inbox.
>=20
> --=20
> Scott Leerssen <scott@leerssen.com>
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting =
Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly =
Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RE: nfs root directory security

[Scott Leerssen]

On Wed, 2003-06-18 at 11:27, Heflin, Roger A. wrote:
> Scott,
> 
> If you really want to be scared, try 
> "showmount -a servername"
> This will tell the server to list the clients and what filesystems they have
> mounted.  And unguessable becomes a non-issue, and anyone can grab anyone
> elses data since they know exactly what partition to mount.
> 
> 
> 		Roger
> 

That's the magic of open source...  anything can be turned off if so
desired :)


> > -----Original Message-----
> > From:	Scott Leerssen [SMTP:scott@leerssen.com]
> > Sent:	Wednesday, June 18, 2003 9:28 AM
> > To:	Bogdan Costescu
> > Cc:	Neil Brown; nfs@lists.sourceforge.net
> > Subject:	Re: [NFS] nfs root directory security
> > 
> > I agree with everything you say here, and in a controlled and fairly
> > unchanging environment with clients you trust, exporting to specific
> > clients is a perfectly acceptable solution.  All I'm suggesting is
> > adding an extra "layer of the onion" by restricting the ability to mount
> > read-restricted directories.  It gives us the ability to create
> > mountable filesystems for each server in a path that can not be
> > traversed by mounting higher level directories.
> > 
> > Imagine if the B and C paths of /A/B/C/root are cryptographically
> > generated names, and that C is different for every mount point, B is
> > different for every "repository", and A is simply an anchor in the root
> > of my NAS.  I can export my clients root filesystems as:
> > 
> >    /A 192.168.100.0/255.255.255.0(rw,no_root_squash,...)
> > 
> > If B and C are unmountable and unguessable (without a lot of failed and
> > obvious nfs mount attempts), I don't have to worry about anyone but the
> > intended client mounting its root filesystem (assuming the network is
> > safe from sniffing DHCP and mount requests).  Plus, I don't have to have
> > an entry for every single client.  I could, and that would buy me an
> > added bit of assurance, but I don't need one so it's much easier to
> > maintain hundreds of mount points.
> > 
> > Of course, there's a lot more to securing an NFS environment such as
> > this, particularly when you can't trust the clients to behave.  This
> > tweak just eases the burden of managing exports for hundreds (or
> > thousands) of clients on as many NAS as you can imagine.  The burden is
> > shifted to managing unreadable pathnames in the management software...
> > (sigh).
> > 
> > That's about all I have to add on this... feel free to use the patch or,
> > if you haven't already, delete it from your inbox.
> > 
> > -- 
> > Scott Leerssen <scott@leerssen.com>
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > NFS maillist  -  NFS@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs
-- 
Scott Leerssen <scott@leerssen.com>



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RE: nfs root directory security

[Heflin, Roger A.]

And Scott, you have the DHCP table, write a simple script
to take the info from the DHCP table and generate a proper
exports file based on that info.=20

You aren't doing two separate sets of the same information
separately?   We usually have a original set of files with info
in them (be that our own format, or the DHCP entries, or something
else), and then have scripts to generate the system files,
that would be used from that info, such as the DHCP and exports
entries, so the correct information is only in one place and=20
all others are derivitavies of that original source, this also reduces
mistakes where you are manually adjusting the several sources
and fail to keep everything consistant.

				Roger


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs