Hi,
I'm trying to use NFSv3 with Kerberos 5. I'm using Debian sarge with
Linux 2.6.7, nfs-utils 1.0.6 with the CITI_NFS4_ALL-13 patch, and
util-linux mount 2.12 with the CITI_NFS4_ALL patch.
I added the following definition to /etc/exports:
/tmpexp gss/krb5(rw)
Then, on the client, I run:
# mount -osec=krb5 oberon:/tmpexp /mnt
mount: oberon:/tmpexp failed, reason given by server: Permission denied
and it fails. According to the log:
Aug 23 19:17:48 oberon rpc.mountd: refused mount request from
mallinux.dsv.su.se for /tmpexp (/): not exported
Now, I add the client machine's name to /etc/exports:
/tmpexp gss/krb5(rw) mallinux(ro)
And it works! I can tell that it uses Kerberos because I can write to
the mounted fs if I have a ticket, but not without. The drawback is
that I am now allowing AUTH_SYS mounting as well, which I want to
avoid. Is this a bug in mountd? Is it difficult to fix?
--
Pelle
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 m=E5 , 30/08/2004 klokka 13:17, skreiv J. Bruce Fields:
> I believe (can't find the right language now) that RFC2623 says it's OK
> for the server to allow the client to do MOUNT requests and a few
> filesystem requests (sufficient for statfs) without rpcsec_gss, even on
> rpcsec_gss exports. Our server and mountd currently do *not* do that.
Ah... I keep forgetting the server...
Right. The RFC says that the NFS server should allow AUTH_SYS
authenticated NFSPROC3_FSINFO (NFSv3) and NFSPROC_GETATTR+NFSPROC_STATFS
(NFSv2) calls on the root filehandle (and *only* on the root
filehandle).
mountd should always support AUTH_SYS, so no changes required there
(apart from the need to add the supported RPCSEC_GSS pseudoflavours to
the "auth_flavors" list).
As far as I know, nobody (not even Sun) has set up NLM to work with
RPCSEC_GSS either.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Aug 30, 2004 at 01:45:33PM -0400, Trond Myklebust wrote:
> P? m? , 30/08/2004 klokka 13:17, skreiv J. Bruce Fields:
>
> > I believe (can't find the right language now) that RFC2623 says it's OK
> > for the server to allow the client to do MOUNT requests and a few
> > filesystem requests (sufficient for statfs) without rpcsec_gss, even on
> > rpcsec_gss exports. Our server and mountd currently do *not* do that.
>
> Right. The RFC says that the NFS server should allow AUTH_SYS
> authenticated NFSPROC3_FSINFO (NFSv3) and NFSPROC_GETATTR+NFSPROC_STATFS
> (NFSv2) calls on the root filehandle (and *only* on the root
> filehandle).
And also, though it seems to be just implicit, it expects you to be able
to do MOUNT.
Since we specify the rpcsec_gss security flavor as the client in
/etc/exports, in the place of the ip address/network/whatever, this
means in practice we'd need to allow MOUNT from any ip address for a
filesystem that's exported to rpcsec_gss. Which I suppose is OK, though
I don't understand why clients really want to do that.
> mountd should always support AUTH_SYS, so no changes required there
> (apart from the need to add the supported RPCSEC_GSS pseudoflavours to
> the "auth_flavors" list).
> As far as I know, nobody (not even Sun) has set up NLM to work with
> RPCSEC_GSS either.
Well, I suppose unauthenticated locks are a DOS at worse. But the
lookup of the initial filehandle seems more security-critical to me.
--Bruce Fields
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust:
> This is already implemented...
>
> The RPCSEC_GSS implementation that is in linux-2.6.x already follows the
> guidelines in RFC2623 when you mount an NFSv2 or v3 partition. (The same
> RFC also includes a brief discussion of the security implications of
> this model.)
>
> You'll need a patched version of "mount" though. The one distributed as
> part of Fedora Core 2 should work...
I looked through the FC2 util-linux patches and they seem to be mostly
identical to the CITI patches regarding the Kerberos support. And I've
already applied the CITI patches.
--
Pelle
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
J. Bruce Fields:
> I think that adding rpcsec_gss support to the userland utilities, and
> making it easy for people to distribute keytabs to their clients, is the
> better long-term solution than enabling RFC2623's workarounds. But
> maybe too many clients already expect to be able to mount with auth_sys
> only.
I think there are some benefits with allowing mounting without
requiring a keytab. For example, I'd like to give my users the ability
to mount their home directories from outside of the department
(e.g. their home computers). I don't think it would be practical to
distribute keytabs to all of them, and in many cases it simply doesn't
work (dynamic IPs, NAT, etc.).
It would also be nice to be able to fallback to something similar to
auth_sys with all_squash in case there's no ticket/keytab present for
the current user. This is roughly how AFS behaves. It's not too
important, though.
--
Pelle
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 m=E5 , 30/08/2004 klokka 14:04, skreiv J. Bruce Fields:
> Since we specify the rpcsec_gss security flavor as the client in
> /etc/exports, in the place of the ip address/network/whatever, this
> means in practice we'd need to allow MOUNT from any ip address for a
> filesystem that's exported to rpcsec_gss. Which I suppose is OK, though
> I don't understand why clients really want to do that.
See the RFC. It was basically Sun's decision in order to avoid having to
assign machine credentials to their automounters. If you want your
server to work with SunOS clients, then that's all pretty mandatory.
> > mountd should always support AUTH_SYS, so no changes required there
> > (apart from the need to add the supported RPCSEC_GSS pseudoflavours to
> > the "auth_flavors" list).
> > As far as I know, nobody (not even Sun) has set up NLM to work with
> > RPCSEC_GSS either.
>=20
> Well, I suppose unauthenticated locks are a DOS at worse. But the
> lookup of the initial filehandle seems more security-critical to me.
What can an attacker do with that filehandle?
Actually re-reading the RFC, it does not actually restrict MOUNT to
AUTH_SYS-only, but again - interoperability with Solaris automounters
means that it is pretty much expected...
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tue, 24 Aug 2004, Per Olofsson wrote:
> And it works! I can tell that it uses Kerberos because I can write
> to the mounted fs if I have a ticket, but not without. The drawback
> is that I am now allowing AUTH_SYS mounting as well, which I want
> to avoid. Is this a bug in mountd? Is it difficult to fix?
It's a bug in mountd yes. J Bruce Fields had actually sent me a wee
patch to try fix it for me to test a good while ago, but I havnt
gotten back to looking at NFSv3+GSS since then:
>From [email protected] Wed Jun 2 22:29:52 2004
Date: Wed, 2 Jun 2004 17:29:21 -0400
From: J. Bruce Fields <[email protected]>
To: Paul Jakma <[email protected]>
Subject: Re: [NFS] gss/krb doesnt work with nfsv3?
[snippage]
mountd currently always returns AUTH_NULL and AUTH_SYS as the allowable flavors
in mount replies. We want it to also return gss flavors when appropriate.
For now as a hack we just have it always return AUTH_KRB5 as well.
utils/mountd/mountd.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff -puN utils/mountd/mountd.c~mountd_flavors utils/mountd/mountd.c
--- nfs-utils-1.0.6/utils/mountd/mountd.c~mountd_flavors 2004-05-25 14:39:22.000000000 -0400
+++ nfs-utils-1.0.6-bfields/utils/mountd/mountd.c 2004-06-01 15:03:22.000000000 -0400
@@ -228,7 +228,8 @@ mount_pathconf_2_svc(struct svc_req *rqs
bool_t
mount_mnt_3_svc(struct svc_req *rqstp, dirpath *path, mountres3 *res)
{
- static int flavors[] = { AUTH_NULL, AUTH_UNIX };
+#define AUTH_GSS_KRB5 390003
+ static int flavors[] = { AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5};
struct nfs_fh_len *fh;
xlog(D_CALL, "MNT3(%s) called", *path);
@@ -237,7 +238,8 @@ mount_mnt_3_svc(struct svc_req *rqstp, d
ok->fhandle.fhandle3_len = fh->fh_size;
ok->fhandle.fhandle3_val = fh->fh_handle;
- ok->auth_flavors.auth_flavors_len = 2;
+ ok->auth_flavors.auth_flavors_len
+ = sizeof(flavors)/sizeof(flavors[0]);
ok->auth_flavors.auth_flavors_val = flavors;
}
return 1;
_
regards,
--
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A
Fortune:
Exceptions prove the rule, and wreck the budget.
-- Miller
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Aug 30, 2004 at 02:41:28AM +0100, Paul Jakma wrote:
> On Tue, 24 Aug 2004, Per Olofsson wrote:
>
> >And it works! I can tell that it uses Kerberos because I can write
> >to the mounted fs if I have a ticket, but not without. The drawback
> >is that I am now allowing AUTH_SYS mounting as well, which I want
> >to avoid. Is this a bug in mountd? Is it difficult to fix?
>
> It's a bug in mountd yes. J Bruce Fields had actually sent me a wee
> patch to try fix it for me to test a good while ago, but I havnt
> gotten back to looking at NFSv3+GSS since then:
This doesn't fix the problem Per Olofsson describes, which is that
unless you use nfsv4, there's no way to export to krb5 without also
exporting vi auth_sys.
Since mountd itself doesn't currently have rpcsec_gss support (and, on
the client side, neither does mount), MOUNT requests are going to use
auth_sys. So mountd is going to decide whether to respond based on
their IP address.
It'd seem that the right solution is to add rpcsec_gss support to mount
and mountd, which shouldn't be a big project, so if you export only to
krb5 then you also answer krb5-protected mount requests. I don't know
whether other clients will like that, though.
--Bruce Fields
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
J. Bruce Fields:
> This doesn't fix the problem Per Olofsson describes, which is that
> unless you use nfsv4, there's no way to export to krb5 without also
> exporting vi auth_sys.
>
> Since mountd itself doesn't currently have rpcsec_gss support (and, on
> the client side, neither does mount), MOUNT requests are going to use
> auth_sys. So mountd is going to decide whether to respond based on
> their IP address.
>
> It'd seem that the right solution is to add rpcsec_gss support to mount
> and mountd, which shouldn't be a big project, so if you export only to
> krb5 then you also answer krb5-protected mount requests. I don't know
> whether other clients will like that, though.
OK, I understand. I don't really need authenticated mount requests
though, I only need authenticated file system accesses. In other
words, I don't care who mounts the file system as long as they can't
impersonate a user without a valid ticket. Is this easier to
implement? Does it have any other security implications?
--
Pelle
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 m=E5 , 30/08/2004 klokka 11:45, skreiv Per Olofsson:
> OK, I understand. I don't really need authenticated mount requests
> though, I only need authenticated file system accesses. In other
> words, I don't care who mounts the file system as long as they can't
> impersonate a user without a valid ticket. Is this easier to
> implement? Does it have any other security implications?
This is already implemented...
The RPCSEC_GSS implementation that is in linux-2.6.x already follows the
guidelines in RFC2623 when you mount an NFSv2 or v3 partition. (The same
RFC also includes a brief discussion of the security implications of
this model.)
You'll need a patched version of "mount" though. The one distributed as
part of Fedora Core 2 should work...
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Aug 30, 2004 at 12:45:02PM -0400, Trond Myklebust wrote:
> P? m? , 30/08/2004 klokka 11:45, skreiv Per Olofsson:
>
> > OK, I understand. I don't really need authenticated mount requests
> > though, I only need authenticated file system accesses. In other
> > words, I don't care who mounts the file system as long as they can't
> > impersonate a user without a valid ticket. Is this easier to
> > implement? Does it have any other security implications?
>
> This is already implemented...
>
> The RPCSEC_GSS implementation that is in linux-2.6.x already follows the
> guidelines in RFC2623 when you mount an NFSv2 or v3 partition.
I believe (can't find the right language now) that RFC2623 says it's OK
for the server to allow the client to do MOUNT requests and a few
filesystem requests (sufficient for statfs) without rpcsec_gss, even on
rpcsec_gss exports. Our server and mountd currently do *not* do that.
Since they also don't support rpcsec_gss, that means we're in the
unfortunate position that the only practical way to mount an nfsv2/3
filesystem with krb5 right now is to first make sure the filesystem is
also exported to the client (read-only should suffice) via auth_sys.
I think that adding rpcsec_gss support to the userland utilities, and
making it easy for people to distribute keytabs to their clients, is the
better long-term solution than enabling RFC2623's workarounds. But
maybe too many clients already expect to be able to mount with auth_sys
only.
--b.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Aug 30, 2004 at 06:25:14PM -0400, Trond Myklebust wrote:
> P? m? , 30/08/2004 klokka 14:04, skreiv J. Bruce Fields:
> > Well, I suppose unauthenticated locks are a DOS at worse. But the
> > lookup of the initial filehandle seems more security-critical to me.
>
> What can an attacker do with that filehandle?
One attack that rpcsec_gss is designed to prevent is spoofing of
server's replies to the client. The client needs to be able to trust
the root filehandle returned by the server; an attacker could probably
do some interesting things by feeding the client faked replies with
incorrect filehandles.
> Actually re-reading the RFC, it does not actually restrict MOUNT to
> AUTH_SYS-only, but again - interoperability with Solaris automounters
> means that it is pretty much expected...
Yeah, OK, but it's unfortunate. It would be better just to require the
automounter to have credentials of some sort.
--Bruce Fields
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs