[TUHS] NFS & Kerberos woes...

[TUHS] NFS & Kerberos woes...

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

Do any fellow TUHS subscribers have any experience with NFS, 
particularly in combination with Kerberos authentication?

I'm messing with something that is making me think that Kerberos 
authentication (sec=krb5{,i,p}) usurps no_root_squash.

Meaning that root can't access files owned by other users with go-rwx. 
Almost as if no_root_squash wasn't configured on the export.

Does anyone have a spare bone that they would be willing to throw my way?



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

Re: [TUHS] NFS & Kerberos woes...

[Larry McVoy]

I'm an NFS guy, learned it a bit at uwisc and then a lot more at Sun. 
But Sun didn't do the Kerberos stuff, at least while I was there.

Didn't Kerberos come from MIT?  If so, I bet anything that Ted Ts'o
would know the details.  My guess is it was part of project athena
and I think that overlaps with Ted.  Yo, Ted, Merry Christmas,
what about this Kerberos authentication stuff?  :)

On Tue, Dec 25, 2018 at 05:49:49PM -0700, Grant Taylor via TUHS wrote:
> Do any fellow TUHS subscribers have any experience with NFS, particularly in
> combination with Kerberos authentication?
> 
> I'm messing with something that is making me think that Kerberos
> authentication (sec=krb5{,i,p}) usurps no_root_squash.
> 
> Meaning that root can't access files owned by other users with go-rwx.
> Almost as if no_root_squash wasn't configured on the export.
> 
> Does anyone have a spare bone that they would be willing to throw my way?
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 



-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] NFS & Kerberos woes...

[Theodore Y. Ts'o]

On Tue, Dec 25, 2018 at 06:01:19PM -0800, Larry McVoy wrote:
> I'm an NFS guy, learned it a bit at uwisc and then a lot more at Sun. 
> But Sun didn't do the Kerberos stuff, at least while I was there.
> 
> Didn't Kerberos come from MIT?  If so, I bet anything that Ted Ts'o
> would know the details.  My guess is it was part of project athena
> and I think that overlaps with Ted.  Yo, Ted, Merry Christmas,
> what about this Kerberos authentication stuff?  :)

So the way Kerberized NFS was used at Project Athena was that after
you authenticated as some Kerberos principal, say, such as
"tytso@ATHENA.MIT.EDU", there was mapping function/database which
would map that Kerberos authentication to a user id --- say, 15806.

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:

<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

Because of the Kerberos authentication for tytso@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.  The mapping database and the Hesiod
DNS zone files are created from administration management system
called Moira.

This is important, because access checks are going to both be done on
the client side, as well as the server side.  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).
It does *not* affect the uid/gid returned by stat(2) / getattr
request.

All of this is saying, yes, of *course* Kerberos authenticated NFS
turns off no_root_squash.  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!?!

Now, I believe you *could* configure in the mapping database that
authentication from some Kerberos principal such as
"tytso/root@ATHENA.MIT.EDU" or "host/cwcc.mit.edu@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.

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 (since MIT students had physical access, and there's
nothing quite as dangerous than a bored MIT student).  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".

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.

Cheers,
	
						- Ted

Re: [TUHS] NFS & Kerberos woes...

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 7810 bytes --]

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@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@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@ATHENA.MIT.EDU" or "host/cwcc.mit.edu@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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

Re: [TUHS] NFS & Kerberos woes...

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On 12/25/18 7:01 PM, Larry McVoy wrote:
> I'm an NFS guy, learned it a bit at uwisc and then a lot more at Sun. 
> But Sun didn't do the Kerberos stuff, at least while I was there.

That sort of surprises me.  I guess I had assumed that NFS was Sun 
centric.  Though I shouldn't be surprised that someone else stood on 
Sun's shoulders and extended NFS.  Especially when (I think that) 
Kerberos MIT centric.

> Didn't Kerberos come from MIT?  If so, I bet anything that Ted Ts'o 
> would know the details.  My guess is it was part of project athena and 
> I think that overlaps with Ted.  Yo, Ted, Merry Christmas, what about 
> this Kerberos authentication stuff?  :)

Thank you for the response Larry.  It's amazing what can be learned by 
participating in the TUHS mailing list & community.  :-D



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

Re: [TUHS] NFS & Kerberos woes... — SOLVED

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

On 12/25/18 5:49 PM, Grant Taylor via TUHS wrote:
> Do any fellow TUHS subscribers have any experience with NFS, 
> particularly in combination with Kerberos authentication?

After much toil and tribulation, I've managed to get things working.

> I'm messing with something that is making me think that Kerberos 
> authentication (sec=krb5{,i,p}) usurps no_root_squash.

I've found that no_root_squash is still equally as applicable in 
Kerberized NFS as it is in non-Kerberized NFS.  no_root_squash actually 
still does the same thing in Kerberized NFS.

I figured out (by grinding through possible options) that I needed to do 
the following:

Add a new principal, root/host.sub.domain.tld, and add it to host's 
(system wide) keytab file.

I also needed to configure and enable translations in the 
/etc/idmapd.conf file /on/ /the/ /NFS/ /server/.

--8<--
[Static]
root/host.sub.domain.tld = root

[Translation]
GSS-Methods = static,nsswitch
-->8--

Hopefully this will help someone trying to do something similar in the 
future.

Now, services running as root (sshd) are able to read files 
(authorized_keys) that root doesn’t have permission to read (owned by 
user and 0600) on an NFS mount (/home) that is using Kerberos 
authentication.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

Re: [TUHS] NFS & Kerberos woes...

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

On 12/25/18 9:49 PM, Theodore Y. Ts'o wrote:
> Now, I believe you *could* configure in the mapping database 
> that authentication from some Kerberos principal such as 
> "tytso/root@ATHENA.MIT.EDU" or "host/cwcc.mit.edu@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.

Ted, you ultimately pointed me down the proper path.

My first few attempts at implementing what you were suggesting, 
including (re)using the host/client.sub.domain.tld@REALM, didn't work 
out as desired.

After much trial and tribulation, I did manage to get it working using a 
different principal, root/client.sub.domain.tld@REALM.

See my previous reply to my original message for more details.

Thank you again for the very detailed reply Ted.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]