From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 5611f207 for ; Wed, 26 Dec 2018 08:46:05 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 60083A366F; Wed, 26 Dec 2018 18:46:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id EF442A3667; Wed, 26 Dec 2018 18:45:27 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=tnetconsulting.net header.i=@tnetconsulting.net header.b="FAzY7UOz"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B0306A3667; Wed, 26 Dec 2018 18:45:24 +1000 (AEST) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [45.33.28.24]) by minnie.tuhs.org (Postfix) with ESMTPS id A8E9C93EA4 for ; Wed, 26 Dec 2018 18:45:23 +1000 (AEST) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id wBQ8jLQl022902 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 26 Dec 2018 02:45:23 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1545813923; bh=R3oe8QHo2aDelRAMepCL/yDH15Zrt+dkBlOAGteUOKY=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=FAzY7UOzZhOASFF/dDlutPZM53zho32fENz+WsN6soLFeCL+evNuVkhXdjT991z9S lUww57d2Yh2L0i2WJeEK9dQVDfqQ8v13aeZj289VoEFH14O7JhMWtrPD02z7EkQqnB 7q9vwIndtsRtyS8lED5il6kDyT1kaj2yBBhlJL2I= To: tuhs@minnie.tuhs.org References: <20181226020119.GF18199@mcvoy.com> <20181226044920.GB4158@mit.edu> Organization: TNet Consulting Message-ID: Date: Wed, 26 Dec 2018 01:45:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181226044920.GB4158@mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010309020501070004040708" Subject: Re: [TUHS] NFS & Kerberos woes... X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Grant Taylor via TUHS Reply-To: Grant Taylor Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a cryptographically signed message in MIME format. --------------ms010309020501070004040708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable First: Thank you for the very detailed response Ted. I hope that my=20 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=20 > after you authenticated as some Kerberos principal, say, such as=20 > "tytso@ATHENA.MIT.EDU", there was mapping function/database which would= =20 > 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).=20 Please correct me if that's incorrect. > On the Athena client, at login time /bin/login (or a PAM module)=20 > would do a Hesiod lookup for (tytso, passwd) in the athena.mit.edu=20 > Hesiod domain. This translate to a DNS lookup for class=3DHS, type=3DT= XT,=20 > 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=20 store information, meta data, about accounts, which is typically stored=20 in /etc/passwd. The important distinction is that password /=20 authentication information is decidedly NOT stored in DNS or LDAP.=20 Instead, authentication is solely in the Kerberos realm. (Pun is=20 somewhat intended.) Is that correct? > {/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/athen= a/tcsh I'm taking that to be the Hesiod equivalent of "getent passwd tytso".=20 Is that correct? > Because of the Kerberos authentication for tytso@ATHENA.MIT.EDU, the=20 > Kerberos-authenticated NFS server would map all NFS requests (regardles= s=20 > of the uid/gid in the NFS RPC) to the uid in the mapping database ---=20 > in my case, 15806. If I'm understanding you correctly, you're stating that Kerberos=20 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=20 dependent on trusting the NFS client machine. > This is important, because access checks are going to both be done on=20 > the client side, as well as the server side. I hadn't thought about this before. I guess client side might be an=20 optimization for clients. But I would only trust server side.=20 (Likewise with client side JavaScript compared to server side=20 $LanguageDejure.) > And the Kerberos NFS mapping only affects the uid/gid in the used for=20 > server-side access control checks (e.g., it replaces the uid/gid in the= =20 > 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=20 means that my "getent passwd" method mentioned above is flawed. > All of this is saying, yes, of *course* Kerberos authenticated NFS turn= s=20 > off no_root_squash. Hum. I have no problem accepting that Kerberized NFS wants to not blindly=20 trust the uid & gid that the NFS client claims. But I would think that an authenticated root account would satisfy=20 Kerberized NFS and allow uid & gid 0. As in we trust the Kerberos=20 authentication, and retrieved uid & gid 0 from the directory (Hesiod or=20 LDAP). Thus I would expect a trusted uid & gid of 0 to be allowed to=20 access files despite what the file system permissions say. Though, as sure as I type that, I wonder about "an authenticated root=20 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=20 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=20 single common root account. The use case that I'm working with, which works perfectly fine with sec=3D= 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=3Dkrb5{,i,p}. It seems as = if root can't access files that standard file system permissions=20 prohibit access to. As if root_squash was in effect. I /think/ that root has a valid Kerberos TGT, thus can properly=20 authenticate to NFS and as such /should/ be able to access=20 /home/tytso/.ssh/authorized_keys. Perhaps I am making a bad assumption in thinking the system's keytab is=20 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=20 > willing to blindly trust the uid/gid asserted by the client and grant=20 > access on that basis. If you are going to allow the the NFS server to = go,=20 > "Hurr, durr... you are claiming a uid of 0 --- OK! You can do whatever= =20 > you want." ---- why bother with Kerberos authentication at all in the=20 > fairst place!?! I'm not trying to blindly have root access files that it doesn't have=20 permission to. I'm perfectly happy to have root authenticate to Kerberos and have the=20 proper tickets to satisfy NFS. I /thought/ I was doing exactly that.=20 Perhaps I'm mistaken. > Now, I believe you *could* configure in the mapping database=20 > that authentication from some Kerberos principal such as=20 > "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= =20 > 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=20 might be part of what I /think/ I am wanting and that I should do some=20 more reading about it. I could also be mistaken in thinking that I want (properly=20 authenticated) root to have access like I'm describing. > This wasn't somethingh we generally did, though, since the general=20 > model we used is that root on the local client should mean _nothing_.=20 > Indeed, on Public Athena workstations, the assumption was that anyone=20 > could get root Understandable. That makes sense. Especially in that situation. This=20 is also one of the reasons that I'm questioning if my logic about=20 allowing an authenticated root having access. But, I'm not (yet) aware=20 of another way to enable sshd, running as root, to access=20 ~/.ssh/authorized_keys files from an NFS export. I'd be happy to hear=20 about other ways. Aside: I'm actually authenticating to SSH using Kerberos via GSSAPI.=20 I'm wanting access to ~/.ssh/authorized_keys file for another PAM module = for something else. (This works perfectly fine with sec=3Dsys or local=20 non-NFS files.) > (since MIT students had physical access, and there's nothing quite as=20 > dangerous than a bored MIT student). LOL I get it. > Hence, during thet time when I was an undergraduate, the public root=20 > password as "mrroot". Anyone could su to root thus eliminating the=20 > challenge of "breaking root". Ya. Knowing the ""secret really take the wind out of the sails of=20 trying to learn the ""secret. > As a result, we never tried to give uid 0 special server-side permissio= ns,=20 > since it went against the model that IP address-based authentication=20 > and blind-faith trust in assertions of uid=3D=3D0 from NFS clients as j= ust=20 > 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=20 ~/.ssh/authorized_keys with 0600 permissions. --=20 Grant. . . . unix || die --------------ms010309020501070004040708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Cy4wggVAMIIEKKADAgECAhEA01fiRe1k2R6LEQCcImIMYTANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgxMTE4MDAw MDAwWhcNMTkxMTE4MjM1OTU5WjArMSkwJwYJKoZIhvcNAQkBFhpndGF5bG9yQHRuZXRjb25z dWx0aW5nLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANgOhvncDgc4KAlD +pyhFpw6wCfeERlSOAXowjdTjlOR2zcIgzL0TM9A+hkSv2wsVh6fn6VvHGxKrLemReiGd7fQ 15Y9J/pxKOmShkw9DDtFsa18ozydp95X2IuzY8Z2JukxouqrfpSH4fOrrHLkOgvlFG4xaQHW 0KB8xUP5DFWyyZM5QCdq278GSJ5pUd+B6qmzwHESNF6syyvgLppXkFatLTz8pWf6eEngDA0Y 3fQ3Q2gnbgpryRhVQMa1GjQJ7LDroUGQhX2zBWePW+sShiTwo8jADYKsbgSGtvZ/42A8zxyg s9YZMHQoCeeuLNuX/MBp9rCTl5nlzP3jGWQTC5ECAwEAAaOCAfAwggHsMB8GA1UdIwQYMBaA FIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQg2PeEKxHWd4FaHe0T+gqAOWkC1jAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRT MFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29t b2RvY2EuY29tMCUGA1UdEQQeMByBGmd0YXlsb3JAdG5ldGNvbnN1bHRpbmcubmV0MA0GCSqG SIb3DQEBCwUAA4IBAQCPxlHHG57PA5GUYlQuC8VHB7TcMQeEJKnB/S+bamyrck4vpIEaF9rG EM+OnAQsJzSkSVHD2707jxh1ng0jrsH2+F9qNGTpCksXo0fMqm4tf28Ag092+CZ5sfdjVZ4E ELG4xNhFZF9/aFaAY7RIeJ89Vvn6s6BnKsaAPjVB/sO+5gIm0BIeoVauq71ue6jS7o2Jn94o BuAhjuh34gk/Wxzcku96MLmEwCY63GWWKVRYbqrDhqROmnQPdyrDYrU8uD0vb4SAdpSKfRqO DrerlQgX3euyYqcnVJSA8Ec+NdiJrGKXW76C7DrTi7IxDgjIHL+DPyFgtj+p6wYOEkYJwKtp MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBS U0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpY PpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1 wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP 1cHWse9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5 LFLG3yQK+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy 1DAdBgNVHQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0 dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHEGCCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJ CAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/h k6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWl nhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNm NppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tU U1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR 6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ 16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8ao rYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5 v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfK ehIxggQ4MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx PTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQDTV+JF7WTZHosRAJwiYgxhMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEyMjYwODQ1MjFaMC8GCSqG SIb3DQEJBDEiBCCa/YxLcjZypanH0/ePjoSg+zurp76lmuJbSwGjUCOWyDBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEE AYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0 ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYD VQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA01fiRe1k2R6LEQCcImIMYTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA01fiRe1k2R6LEQCcImIM YTANBgkqhkiG9w0BAQEFAASCAQAM40AzAQ2WtevkMJz+uV3ixTYt1HOx1yt+wo9yrpbyHn7y 68Czv4KLikPuWvmKhP07hGRecC3iQrUlJKvvu4ftCNGmwhVqeflVoV+EGAOMh1RvJ9Nm3AAg RUw4DchzPini2R7S+NYW6qrEHJx4JWJFAJ0tx8IjY/g/8CR4QIgFcjy6iJee1Mwj8vQio6yG G8kg27VHgQRLX9bY8PFQ6FObd+rka760Ew7U+6eoj9f12pz5tzqi+dLc1GHqJKUtS5c6DecO wke2/ZU05IyETSUl1c4n2V6efV0IGPYZZruSzrufTphubMKHLGkUet8GXHBzuPwBrArNaBue pDV1DHt/AAAAAAAA --------------ms010309020501070004040708--