[PATCH] Secure user authentication for NFS using RPCSEC_GSS [0/6]

[PATCH] Secure user authentication for NFS using RPCSEC_GSS [0/6]

[Trond Myklebust]

Hi Linus,

 The following set of 6 patches implements support for the RPCSEC_GSS
security protocol (authentication only) and the Kerberos V5 security
mechanism.
 These patches constitute a resend (modulo some bugfixes) of a set
that was originally sent to you and the L-K list on 31/10/2002. I
received no comment on them at the time (and they were not immediately
applied), and so I've been waiting for the general hubbub after the
feature freeze to die down before.

RPCSEC_GSS is the security mechanism that is mandated for all compliant
NFSv4 implementations by RFC3010. It provides a protocol for negotiating
secure authentication and data transfers on a per-user basis. It does
so in a manner that does not depend on the actual security mechanism
that is used, and so can support a variety of such mechanisms. The
mechanisms that are mandated for NFSv4 by RFC3010 are Kerberos V5 (see
RFC1964), SPKM-3 (RFC2025), and LIPKEY (RFC2847).

The actual security negotiation can be done out of band, so it makes
sense to delegate as much of this as possible to a userland
daemon. The result of negotiation is a security 'context' which is
cached in the kernel, and is subsequently used for authentication (as
part of the credential in the RPC header) and/or for data
integrity/privacy protection (using whatever crypto mechanism your
chosen security mechanisms support).

Our wish is to provide basic kernel RPC client support for the generic
RPCSEC_GSS protocol, and for communicating with a userland daemon that
does the actual the security context negotiation with the RPC server.
Communication between kernel and userland is done over a set of named
pipes (in much the same way as the CODA upcall/downcall is done) in a
private ramfs-like filesystem.

Cheers,
  Trond

Re: [PATCH] Secure user authentication for NFS using RPCSEC_GSS [0/6]

[Jeff Garzik]

On Mon, Jan 13, 2003 at 01:12:50AM +0100, Trond Myklebust wrote:
> Our wish is to provide basic kernel RPC client support for the generic
> RPCSEC_GSS protocol, and for communicating with a userland daemon that
> does the actual the security context negotiation with the RPC server.
> Communication between kernel and userland is done over a set of named
> pipes (in much the same way as the CODA upcall/downcall is done) in a
> private ramfs-like filesystem.

Well, AFS also wants Kerb [but a weird Kerb4 variant IIRC], but,
OTOH why not do all this authentication and stuff in userspace?

Several other projects through the years have done similar things, where
a userspace daemon handles auth and such, and then passes an fd into
the kernel via ioctl [or write(2)ing fd value to a mini-ramfs VFS node].

Re: [PATCH] Secure user authentication for NFS using RPCSEC_GSS [0/6]

[Jeff Garzik]

On Sun, Jan 12, 2003 at 09:19:51PM -0500, Jeff Garzik wrote:
> OTOH why not do all this authentication and stuff in userspace?

Please forgive me:  ENOCAFFEINE.  I re-read your mail...

Re: [PATCH] Secure user authentication for NFS using RPCSEC_GSS [0/6]

[Dax Kelson]

On Sun, 2003-01-12 at 17:12, Trond Myklebust wrote:
> Hi Linus,
> 
>  The following set of 6 patches implements support for the RPCSEC_GSS
> security protocol (authentication only) and the Kerberos V5 security
> mechanism.

As a user and sysadmin, I've been waiting for this for a LONG time.
Standard NFS security/authentication sucks rocks. Without this NFS home
directory servers are just waiting to be ransacked by a rouge (or
compromised) root user on a client machine.

NFSv4 w/RPSEC_GSS is finally a native UNIX filesharing solution that I
don't have to be ashamed of when hanging with admins of those "other
OSes".

Dax

Re: [PATCH] Secure user authentication for NFS using RPCSEC_GSS [0/6]

[Paul Jakma]

On 12 Jan 2003, Dax Kelson wrote:

> Standard NFS security/authentication sucks rocks. Without this NFS home
> directory servers are just waiting to be ransacked by a rouge (or
> compromised) root user on a client machine.

AIUI, A root user still can. The users krbv5 credentials will
generally have been cached to storage. (though i suppose one could
mount that storage via NFS and use root_squash, but that's little 
protection.).

> NFSv4 w/RPSEC_GSS is finally a native UNIX filesharing solution that
> I don't have to be ashamed of when hanging with admins of those
> "other OSes".

Unless NFSv4 has dealt with the problem above, it isnt much protection 
from rogue root users.

> Dax

regards,
-- 
Paul Jakma	Sys Admin	Alphyra
	paulj@alphyra.ie
Warning: /never/ send email to spam@dishone.st or trap@dishone.st

Re: [PATCH] Secure user authentication for NFS using RPCSEC_GSS [0/6]

[Trond Myklebust]

>>>>> " " == Jeff Garzik <jgarzik@pobox.com> writes:

     > On Sun, Jan 12, 2003 at 09:19:51PM -0500, Jeff Garzik wrote:
    >> OTOH why not do all this authentication and stuff in userspace?

     > Please forgive me: ENOCAFFEINE.  I re-read your mail...

Right. This is doing exactly what you suggested ;-).

All that is added to the kernel is the code that we need to repackage
a user context that was negotiated in userspace into the RPC header.

Cheers,
  Trond

Re: [PATCH] Secure user authentication for NFS using RPCSEC_GSS [0/6]

[Trond Myklebust]

>>>>> " " == Paul Jakma <paulj@alphyra.ie> writes:

     > On 12 Jan 2003, Dax Kelson wrote:
    >> Standard NFS security/authentication sucks rocks. Without this
    >> NFS home directory servers are just waiting to be ransacked by
    >> a rouge (or compromised) root user on a client machine.

     > AIUI, A root user still can. The users krbv5 credentials will
     > generally have been cached to storage. (though i suppose one
     > could mount that storage via NFS and use root_squash, but
     > that's little protection.).

Once the root account has been compromised, it is 'Game Over' no
matter what you do. Kerberos or no Kerberos, the simplest way to steal
your identity is simply for the attacker to listen in on your tty
while you are typing your password.

The RPCSEC_GSS security model is not meant to protect you against root
monitoring. It is meant to prevent some third party (on another
machine for instance) from spoofing RPC requests in you name (==
strong authentication), intercepting valid RPC requests and modifying
the payload (== cryptographic data integrity checking), or listening
in on the client/server communication (== data privacy).

Cheers,
  Trond

Re: [PATCH] Secure user authentication for NFS using RPCSEC_GSS [0/6]

[Dax Kelson]

On Mon, 13 Jan 2003, Paul Jakma wrote:

> On 12 Jan 2003, Dax Kelson wrote:
> 
> > Standard NFS security/authentication sucks rocks. Without this NFS home
> > directory servers are just waiting to be ransacked by a rouge (or
> > compromised) root user on a client machine.
> 
> AIUI, A root user still can. The users krbv5 credentials will
> generally have been cached to storage. (though i suppose one could
> mount that storage via NFS and use root_squash, but that's little 
> protection.).

Well, I was trying to keep my email short. Yes, if you login to a 
compromised machine, and then obtain krbv5 credentails the evil root user 
can access/delete/modify your files stored on a RPSEC_GSS NFS server.

With RPSEC_GSS, a compromised machine, on it's own (no logged in users
except evil root), can not access/delete/modify files stored on the NFS
home directory server, which is quite different than the normal case. This 
helps when the exploit-of-the-day hits at 4am Saturday morning.

As a matter of practice you shouldn't leave cached credentials lying
around when you not logged in. Unless you have a very strong reason not
to, kill your ssh-agent and run kdestory on logout (.bash_logout and 
friends).

Dax

[PATCH] Fix RPC client warning in 2.5.58...

[Trond Myklebust]

>>>>> " " == Linus Torvalds <torvalds@transmeta.com> writes:

     > Trond, with the latest stuff I'm getting infinite streams of
     > 	/lockd/clntef03c480 RPC: Couldn't create pipefs entry

This appears to be due to the lockd process starting RPC clients as an
unprivileged user, causing path_walk() to fail. The following patch
should fix it.

Cheers,
  Trond

diff -u --recursive --new-file linux-2.5.58/net/sunrpc/rpc_pipe.c linux-2.5.58-00-fix_warn/net/sunrpc/rpc_pipe.c
--- linux-2.5.58/net/sunrpc/rpc_pipe.c	2003-01-12 22:39:49.000000000 +0100
+++ linux-2.5.58-00-fix_warn/net/sunrpc/rpc_pipe.c	2003-01-14 16:05:21.000000000 +0100
@@ -342,19 +342,19 @@
 static struct rpc_filelist files[] = {
 	[RPCAUTH_lockd] = {
 		.name = "lockd",
-		.mode = S_IFDIR | S_IRUSR | S_IXUSR,
+		.mode = S_IFDIR | S_IRUGO | S_IXUGO,
 	},
 	[RPCAUTH_nfs] = {
 		.name = "nfs",
-		.mode = S_IFDIR | S_IRUSR | S_IXUSR,
+		.mode = S_IFDIR | S_IRUGO | S_IXUGO,
 	},
 	[RPCAUTH_portmap] = {
 		.name = "portmap",
-		.mode = S_IFDIR | S_IRUSR | S_IXUSR,
+		.mode = S_IFDIR | S_IRUGO | S_IXUGO,
 	},
 	[RPCAUTH_statd] = {
 		.name = "statd",
-		.mode = S_IFDIR | S_IRUSR | S_IXUSR,
+		.mode = S_IFDIR | S_IRUGO | S_IXUGO,
 	},
 };
 
@@ -425,7 +425,7 @@
 		return -ENODEV;
 	}
 	nd->mnt = mntget(rpc_mount);
-	nd->dentry = dget(rpc_mount->mnt_sb->s_root);
+	nd->dentry = dget(rpc_mount->mnt_root);
 	nd->last_type = LAST_ROOT;
 	nd->flags = flags;