[ldapext] RFC2307, netgroups, DBIS (was: LDAP work at IETF...)

"michael-catchall@mail.stroeder.local (POP3)" <michael@stroeder.com> Mon, 02 February 2015 18:21 UTC

Return-Path: <michael@stroeder.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 915711A885F for <ldapext@ietfa.amsl.com>; Mon, 2 Feb 2015 10:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.631
X-Spam-Level: *
X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Q8-UVOSLjsZY for <ldapext@ietfa.amsl.com>; Mon, 2 Feb 2015 10:21:19 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2142F1A8859 for <ldapext@ietf.org>; Mon, 2 Feb 2015 10:21:18 -0800 (PST)
Received: from srv4.stroeder.local (srv4.stroeder.local []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (not verified)) by srv1.stroeder.com (Postfix) with ESMTPS id 584081D343; Mon, 2 Feb 2015 19:21:15 +0100 (CET)
Received: from localhost (localhost []) by srv4.stroeder.local (Postfix) with ESMTP id 70A6F1DFF9; Mon, 2 Feb 2015 19:21:15 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.local
Received: from srv4.stroeder.local ([]) by localhost (srv4.stroeder.local []) (amavisd-new, port 10024) with ESMTP id Z7ylCRg5qUQC; Mon, 2 Feb 2015 19:21:09 +0100 (CET)
Received: from nb2.stroeder.local (nb2.stroeder.local []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 27C441CFBB; Mon, 2 Feb 2015 19:21:07 +0100 (CET)
Message-ID: <54CF4F66.5000001@stroeder.com>
Date: Mon, 02 Feb 2015 11:20:22 +0100
From: "michael-catchall@mail.stroeder.local (POP3)" <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32
MIME-Version: 1.0
To: Mark R Bannister <dbis@proseconsulting.co.uk>, ldapext@ietf.org
References: <etPan.54c553b0.19e21bb2.1f2@lpm.local> <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <54C80DB9.10901@stroeder.com> <54C81EBD.3020804@proseconsulting.co.uk> <54C921AB.1090309@stroeder.com> <54CEADBC.5070902@proseconsulting.co.uk>
In-Reply-To: <54CEADBC.5070902@proseconsulting.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/vorOsEFJ94IQG2guS-nMxYQ-lxQ>
Subject: [ldapext] RFC2307, netgroups, DBIS (was: LDAP work at IETF...)
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 18:21:20 -0000

(Changed the subject.)

Mark R Bannister wrote:
> On 28/01/2015 17:51, Michael Ströder wrote:
>>> Rather than attempting to kill off something that is used extensively, and has
>>> actually proved to be very useful in large UNIX/Linux estates (if a bit
>>> clunky), I've embraced them, rationalised them, defined them in a neater and
>>> queryable format, and complemented them with netservices.
>> I'd avoid them and convert access control rules based on netgroups into
>> another schema and let the LDAP server's ACL work through the data.
> Agreed, great for access control.  But I don't see how that will work for the
> other netgroup use-cases.

Which particular netgroup use-cases do you see?
One example is sufficient.

>> My main objective is that not the client system evaluates all the stuff. The
>> client system should not see data not usable on the system. The client system
>> acts as a dumb RFC2307(bis) and sudo-ldap client. Of course the client system
>> still enforces file access permissions etc. locally.
> I agree with you on that point.  Perhaps I could take a similar approach
> with DBIS.  I'm interested, today the NSS library on Linux hosts does not
> have the identity of the requester.  It is quite normal for there to be a
> service account used in the LDAP bind, or perhaps even an anonymous bind.

IMO it's ok to use an individual machine identity to request NSS data from the
LDAP server. But if the machine gets rooted the attacker should not see the
rest of the NSS data for other server/service groups. So my threat model is
that the machine is already out of control.

> The LDAP server can then only usefully filter with ACLs data that is 
> restricted to specific hosts, but not to specific users.  So you are only
> solving half the problem, right?

Filtering more based on identity of end user on a machine would IMO violate
POSIX semantics.
What do others think?

Ciao, Michael.