26 Dec
2018
26 Dec
'18
2:45 p.m.
First: Thank you for the very detailed response Ted. I hope that my
response is worth while.
On 12/25/18 9:49 PM, Theodore Y. Ts'o wrote:
So the way Kerberized NFS was used at Project Athena
was that
after you authenticated as some Kerberos principal, say, such as
"tytso(a)ATHENA.MIT.EDU", there was mapping function/database which would
map that Kerberos authentication to a user id --- say, 15806.
Okay. My (limited) understanding is that I have that functionality with
Kerberos (for authentication) and LDAP (for directory information).
Please correct me if that's incorrect.
On the Athena client, at login time /bin/login (or a
PAM module)
would do a Hesiod lookup for (tytso, passwd) in the athena.mit.edu
Hesiod domain. This translate to a DNS lookup for class=HS, type=TXT,
for tytso.passwd.ns.athena.mit.edu:
It's my understanding that Project Athena used Hesiod data stored in DNS
in place of what I'm storing in LDAP. That is both Hesiod and LDAP
store information, meta data, about accounts, which is typically stored
in /etc/passwd. The important distinction is that password /
authentication information is decidedly NOT stored in DNS or LDAP.
Instead, authentication is solely in the Kerberos realm. (Pun is
somewhat intended.)
Is that correct?
<tytso@cwcc>
{/usr/projects/xfstests-bld/build-64} (master)
1067% hesinfo -lb tytso passwd
hes_to_bind(tytso, passwd) expands to
tytso.passwd.ns.athena.mit.edu
which resolves to
tytso:*:15806:101:Theodore Y. Ts'o,E40-343,38091,:/mit/tytso:/bin/athena/tcsh
I'm taking that to be the Hesiod equivalent of "getent passwd tytso".
Is that correct?
Because of the Kerberos authentication for
tytso(a)ATHENA.MIT.EDU, the
Kerberos-authenticated NFS server would map all NFS requests (regardless
of the uid/gid in the NFS RPC) to the uid in the mapping database ---
in my case, 15806.
If I'm understanding you correctly, you're stating that Kerberos
authenticated NFS uses the uid & gid learned via Kerberos authentication
and ignoring the purported uid & gid from the NFS RPC.
This makes sense.
It also removes the need to trust the NFS RPC which was inherently
dependent on trusting the NFS client machine.
This is important, because access checks are going to
both be done on
the client side, as well as the server side.
I hadn't thought about this before. I guess client side might be an
optimization for clients. But I would only trust server side.
(Likewise with client side JavaScript compared to server side
$LanguageDejure.)
And the Kerberos NFS mapping only affects the uid/gid
in the used for
server-side access control checks (e.g., it replaces the uid/gid in the
NFS RPC request).
ACK
It does *not* affect the uid/gid returned by stat(2) /
getattr request.
Okay. I'm going to have to think about that more. I wonder if that
means that my "getent passwd" method mentioned above is flawed.
All of this is saying, yes, of *course* Kerberos
authenticated NFS turns
off no_root_squash.
Hum.
I have no problem accepting that Kerberized NFS wants to not blindly
trust the uid & gid that the NFS client claims.
But I would think that an authenticated root account would satisfy
Kerberized NFS and allow uid & gid 0. As in we trust the Kerberos
authentication, and retrieved uid & gid 0 from the directory (Hesiod or
LDAP). Thus I would expect a trusted uid & gid of 0 to be allowed to
access files despite what the file system permissions say.
Though, as sure as I type that, I wonder about "an authenticated root
account". As in are there multiple? Or is there a common shared single
root account with uid & gid 0. - I don't know what should be done
there. I think a single common root account would match a single common
tytso account. But I can see the security advantage of not having a
single common root account.
The use case that I'm working with, which works perfectly fine with sec=sys.
/home is mounted off of an export with no_root_squash. So, sshd running
as root can access /home/tytso/.ssh/authorized_keys.
But, this doesn't seem to work when I use sec=krb5{,i,p}. It seems as
if root can't access files that standard file system permissions
prohibit access to. As if root_squash was in effect.
I /think/ that root has a valid Kerberos TGT, thus can properly
authenticate to NFS and as such /should/ be able to access
/home/tytso/.ssh/authorized_keys.
Perhaps I am making a bad assumption in thinking the system's keytab is
sufficient to allow root to authenticate to Kerberos. - I'm relatively
new to Kerberos and still learning the ropes.
The whole point of using Kerberos authentication is so
the server is
willing to blindly trust the uid/gid asserted by the client and grant
access on that basis. If you are going to allow the the NFS server to go,
"Hurr, durr... you are claiming a uid of 0 --- OK! You can do whatever
you want." ---- why bother with Kerberos authentication at all in the
fairst place!?!
I'm not trying to blindly have root access files that it doesn't have
permission to.
I'm perfectly happy to have root authenticate to Kerberos and have the
proper tickets to satisfy NFS. I /thought/ I was doing exactly that.
Perhaps I'm mistaken.
Now, I believe you *could* configure in the mapping
database
that authentication from some Kerberos principal such as
"tytso/root(a)ATHENA.MIT.EDU" or "host/cwcc.mit.edu(a)ATHENA.MIT.EDU"
(you
can use service principals from a Kerberos keytab as a client principal
for the purposes of machine authentication) should be mapped to uid 0.
Hum. The idea of mapping host/$FQDN@$REALM to uid 0 sounds like it
might be part of what I /think/ I am wanting and that I should do some
more reading about it.
I could also be mistaken in thinking that I want (properly
authenticated) root to have access like I'm describing.
This wasn't somethingh we generally did, though,
since the general
model we used is that root on the local client should mean _nothing_.
Indeed, on Public Athena workstations, the assumption was that anyone
could get root
Understandable. That makes sense. Especially in that situation. This
is also one of the reasons that I'm questioning if my logic about
allowing an authenticated root having access. But, I'm not (yet) aware
of another way to enable sshd, running as root, to access
~/.ssh/authorized_keys files from an NFS export. I'd be happy to hear
about other ways.
Aside: I'm actually authenticating to SSH using Kerberos via GSSAPI.
I'm wanting access to ~/.ssh/authorized_keys file for another PAM module
for something else. (This works perfectly fine with sec=sys or local
non-NFS files.)
(since MIT students had physical access, and
there's nothing quite as
dangerous than a bored MIT student).
LOL I get it.
Hence, during thet time when I was an undergraduate,
the public root
password as "mrroot". Anyone could su to root thus eliminating the
challenge of "breaking root".
Ya. Knowing the ""secret really take the wind out of the sails of
trying to learn the ""secret.
As a result, we never tried to give uid 0 special
server-side permissions,
since it went against the model that IP address-based authentication
and blind-faith trust in assertions of uid==0 from NFS clients as just
being silly.
I think I get the reason why you say that and why you did what you did.
That just leaves me looking for another solution to needing to access
~/.ssh/authorized_keys with 0600 permissions.
--
Grant. . . .
unix || die