From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SUBJ_ALL_CAPS autolearn=no 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 7453f5b8 for ; Mon, 5 Nov 2018 17:10:04 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 5F511A23FF; Tue, 6 Nov 2018 03:10:03 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D6663A2162; Tue, 6 Nov 2018 03:09:39 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id CF67FA21EC; Tue, 6 Nov 2018 02:12:23 +1000 (AEST) Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) by minnie.tuhs.org (Postfix) with ESMTPS id 758A6A1FBC for ; Tue, 6 Nov 2018 02:12:23 +1000 (AEST) Received: from medusa.kilonet.net ([72.69.11.12]) by :SMTPAUTH: with ESMTPA id JhUEgwMeYvOCkJhUEgoUcy; Mon, 05 Nov 2018 09:12:22 -0700 Received: from [199.89.231.101] (ender.kilonet.net [199.89.231.101]) by medusa.kilonet.net (8.14.8/8.15.1) with ESMTP id wA5GCLLr001259 for ; Mon, 5 Nov 2018 11:12:21 -0500 (EST) To: tuhs@minnie.tuhs.org References: From: Arthur Krewat Message-ID: <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net> Date: Mon, 5 Nov 2018 11:12:19 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------419B4DFA881D0547E52AB3C2" Content-Language: en-US X-CMAE-Envelope: MS4wfFWkFfGUur0XoVMzg4Qb+TWguBXw9aSQwoWaabsJ0CdS0iZ/3J3IkTgSByp57mLIAZFV29Nd3WlS8h3V+QZzUGTF9pOSCJ0qak7UbyG/IvR74WNUSKJB ogaoCXOPpRaOcaKu2PszN5ELCFXOS78Cmc4lopqXyoTCLJ57wsgjjY1D Subject: Re: [TUHS] YP / NIS / NIS+ / LDAP X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multi-part message in MIME format. --------------419B4DFA881D0547E52AB3C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/5/2018 2:24 AM, Mantas Mikulėnas wrote: >> I'd like to hear more about the security issues. >> >> Did NIS(+) ever encrypt it's communications? (I'm not counting things >> like IPsec transport.) >> >> I'm fairly certain that it was possible to enumerate the directory or >> otherwise scrape most (if not all) of it's contents. > There was `ypcat passwd`, wasn't there? > It was possible, unless you used a network filter on the server, to just ypbind to the server, and then you could ypcat all the maps. Not to mention that without specifying a server, it was a broadcast. So any YP server on the subnet would answer. NIS+ was encrypted over the network, and needed a public key mechanism to authenticate clients. One of which was the server itself. With it's hierarchical architecture, it had a lot of flexibility. I really never understood why people didn't like NIS+. It took an extra step or two to do certain things, but once scripted it was a fairly secure way of handling authentication and directory services. I added new maps to it to do custom .cshrc/.profile scripts using subsections in /usr/local/profile, and a few other customizations. Add it's compatibility mode for NIS/YP, and you could use it to serve not only Sun clients. Operationally, it really was just NIS/YP but with a lot of whiz-bang features. In a deployment of a few hundred mechanical and electrical engineers, with about 50 actual workstations and servers I never had a problem with it. Permissions and other features were actually quite useful. However, I must say, I kept the NIS/YP way of using flat files to regenerate the NIS+ maps each time they were edited. So I guess I cheated a little. art k. --------------419B4DFA881D0547E52AB3C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 11/5/2018 2:24 AM, Mantas Mikulėnas wrote:
I'd like to hear more about the security issues.

Did NIS(+) ever encrypt it's communications?  (I'm not counting things
like IPsec transport.)

I'm fairly certain that it was possible to enumerate the directory or
otherwise scrape most (if not all) of it's contents.

There was `ypcat passwd`, wasn't there?

It was possible, unless you used a network filter on the server, to just ypbind to the server, and then you could ypcat all the maps. Not to mention that without specifying a server, it was a broadcast. So any YP server on the subnet would answer.

NIS+ was encrypted over the network, and needed a public key mechanism to authenticate clients. One of which was the server itself. With it's hierarchical architecture, it had a lot of flexibility.

I really never understood why people didn't like NIS+. It took an extra step or two to do certain things, but once scripted it was a fairly secure way of handling authentication and directory services. I added new maps to it to do custom .cshrc/.profile scripts using subsections in /usr/local/profile, and a few other customizations. Add it's compatibility mode for NIS/YP, and you could use it to serve not only Sun clients.

Operationally, it really was just NIS/YP but with a lot of whiz-bang features. In a deployment of a few hundred mechanical and electrical engineers, with about 50 actual workstations and servers I never had a problem with it. Permissions and other features were actually quite useful.

However, I must say, I kept the NIS/YP way of using flat files to regenerate the NIS+ maps each time they were edited. So I guess I cheated a little.

art k.

--------------419B4DFA881D0547E52AB3C2--