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
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...
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].
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
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
[email protected]
Warning: /never/ send email to [email protected] or [email protected]
>>>>> " " == Jeff Garzik <[email protected]> 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
>>>>> " " == Paul Jakma <[email protected]> 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
On Mon, 13 Jan 2003, Trond Myklebust wrote:
> Once the root account has been compromised, it is 'Game Over' no
> matter what you do.
Yep.
> 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.
good point.
> 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).
yes. sorry, i forgot to restrict my comment to "local users are still
vulnerable to root on that machine". RCPSEC_GSS would close the gap to
root requiring to be rogue on the same machine as the user root is
trying to compromise.
BTW: i too very much look forward to using RPCSEC_GSS. very much
appreciated Trond (et al). !
> Cheers,
> Trond
regards,
--
Paul Jakma Sys Admin Alphyra
[email protected]
Warning: /never/ send email to [email protected] or [email protected]
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Paul Jakma <[email protected]> writes:
> BTW: i too very much look forward to using RPCSEC_GSS. very
> much appreciated Trond (et al). !
Andy's team at CITI deserves most of the credit ;-)
Cheers,
Trond
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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