[2252] in Kerberos
Re: Kerberized NFS
daemon@ATHENA.MIT.EDU (Steve Dyer)
Fri Oct 2 23:06:25 1992
Date: 3 Oct 92 01:28:31 GMT
From: dyer@spdcc.com (Steve Dyer)
To: kerberos@shelby.Stanford.EDU
In article <9210021438.AA02441@beta.lanl.gov> cwm@BETA.LANL.GOV (Christina W Mercier) writes:
>Is anyone using MIT's Kerberized NFS in production?
Customers of DEC's DECathena service are.
>I am interested in finding out:
> What type of implementation, to support the Kerberized mount,
> is required for the NFS clients?
A new mountd RPC is built in to the attach command, a command
which looks up the name of a filesystem, sends the special (unofficial)
mountd RPC request which holds a Kerberos ticket, and then performs
an ordinary mount RPC call and local mount. The Kerberized mountd
RPC can be performed alone using the "nfsid" command, if you don't want
to use attach (actually, I believe they're the same program with links).
Note that there's no client kernel mods here. Any system which has
Kerberos and Sun RPC should be able to use this.
> Can a client do a Kerberized mount to one server and a regular
> mount to another?
Yep. The mount command itself isn't modified.
A NFS server which is "Kerberized" runs a modified kernel with a new system
call, nfsmapctl(), which manipulates so-called credential maps. It also
runs a modified mountd which uses nfsmapctl to install a special credentials
structure in the kernel in response to a Kerberos mountd map request. The
structure contains the user's UID, the IP address of the client, and the
new uid and groups to use in their place when an NFS RPC packet comes in
from that IP address with that UID in the RPC credentials structure.
(In fact, uids are not mapped (new==old) because permission checking is local
to the NFS client.) If an NFS RPC packet is received and no credentials
structure is present in the kernel (and such a structure is installed only
by mountd using the Kerberized mountd RPC request), the credentials for
the NFS operation are changed to "nobody". Conceptually it's quite
similar to what happens when a client with UID 0 tries to perform an
operation on an NFS server, except the criterion here is whether or not
a credentials map has been installed on the server or not.
There are also mountd protocol commands to flush or undo existing maps.
>Does anyone know of any writeups on Kerberized NFS other than the
> Appendix of the "Kerberos: An Authentication Service for Open
> Network Systems" paper by Steiner, Neuman, and Schiller?
I think that's it.
>Any discussion on whether folks think that a Kerberized mount is enough
> protection for an NFS server in these times would also be appreciated.
It's not the end-all and be-all. Like most Athena technologies, it
depends on a single user residing on a workstation, and "owning" it
for the duration of their session. On a timesharing system, people
knowing the root password or someone's password could impersonate other
users of the timessharing system wrt NFS access after the mountd
Kerberos authentication has occurrred. Of course, this is true with
vanilla NFS using UNIX authentication.
I believe that Sun has implemented a Kerberos-based NFS authentication
scheme which is dissimilar to this. I don't know a whole lot about it.
It might even be in Solaris 2.0. Anyone know?
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
