From owner-freebsd-arch@freebsd.org Fri Sep 9 21:07:21 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7EEFBD40DC for ; Fri, 9 Sep 2016 21:07:21 +0000 (UTC) (envelope-from pioto@pioto.org) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C84F99 for ; Fri, 9 Sep 2016 21:07:21 +0000 (UTC) (envelope-from pioto@pioto.org) Received: by mail-ua0-x22a.google.com with SMTP id u68so78565252uau.1 for ; Fri, 09 Sep 2016 14:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pioto-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DlX2UyuyLpPEyQVThK+KU3EAR7e4hjv3As8/IxqclHM=; b=WdsJhLGfs/LkJQr5qFfWq9kJMeh0uvQsarA4JYM7ehnSPvrSwWcKNZ3/DluYbnxqJn kYfkYRTvLohc9G6lwHdz2lAjb1rh72Gcr5ZJ1/8F1VwosbQlkGOrmoKsZWmvhn2Un++U IOTTj1jpEYgn2OBAqWDx5fpjqnlQzCyoQvklt03seqxXes8eUfrn7jCYEuPxUvHBA3fJ KnWa+KXQ/5yRzqDghsaX9UiX0GXAEJ4HowkyL2KGdJctqzsB1zPLJYkFD+qH4MIa9jU+ ZXS8V5DwdUePWX3K/wf7iqgEHuJ7Z4gNKeA+V3PXCBdKJLa6CNrEVrcl2ED8VOVndM2T uEPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DlX2UyuyLpPEyQVThK+KU3EAR7e4hjv3As8/IxqclHM=; b=OAcl1NFpxy6gfPe+jAWugDO+Aqt/8y9qUZEPLtswtSe0Xsk1wV+UXRmvrmZ2NpKohA pSx3SawE+x6kY69ELm45xQsOAupUuS7Wdf5FuIK7NT7yTqbvGPowP6b1IgBYWbndlyIJ 1xeNSQzXeUTuHLNsfY8Y2OGGqGH773hMJPuaM0S1IbmxQ0ePiq9OmuOr1+NFQQnjTjoE J4+IcnYhGI6A9ZHx+ukQUaTHppn0d4LKT7t2sENpc+044xj8XyR5MLCcroh/zjeDjH6P GG6H2xmlXKWnfkNuN6ZyACsOXgzMb5A+UMF3UdDFSaZPJrC9QNCpHEkiToaVeBg9+YSd eDKw== X-Gm-Message-State: AE9vXwP+9sHKr0AMfaG6F5/9zFZJwbG7Iw80lmXCU6Auro8FUnuM84LOmMEZbcCSbyaEm8L91HjbQw6CJFmsVQ== X-Received: by 10.176.65.34 with SMTP id j31mr3505623uad.139.1473455240448; Fri, 09 Sep 2016 14:07:20 -0700 (PDT) MIME-Version: 1.0 References: <22483.5592.653250.726711@hergotha.csail.mit.edu> In-Reply-To: <22483.5592.653250.726711@hergotha.csail.mit.edu> From: Mike Kelly Date: Fri, 09 Sep 2016 21:07:10 +0000 Message-ID: Subject: Re: Trying to think out a hack for NSS and pw(8) To: Garrett Wollman , freebsd-arch@freebsd.org, freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 21:07:21 -0000 You may find that the best way to handle this is to disable enumeration of your LDAP users in NSS. For example, if you're using sssd for your LDAP NSS & PAM provider, it is, in fact, disabled by default. This means that calls to getpwent(3) will only end up enumerating the users in your local files, and not those in LDAP. But, calls to getpwnam(3), getpwuid(3), etc will return the details of a specific username or user id, even if it's only present in LDAP. On Fri, Sep 9, 2016 at 4:11 PM Garrett Wollman wrote: > Presently, we have a bunch of machines under configuration management > (using Puppet, but that's not really relevant here). I'm hoping to > implement LDAP via nsswitch on these machines, but I've run into an > issue: the standard getpw*(3) mechanisms can't tell the difference > between users or groups in the local databases and those in the remote > LDAP database. We need Puppet to manage entries for users and groups > in the local database, without respect to what entries might be > imported from LDAP (because they are supposed to override the data > returned by LDAP). Puppet invokes pw(8) to actually perform the > modifications, but I suspect it also uses native code from the Ruby > standard library to actually do pre-modification lookups. > > Looking at the code in both nss-pam-ldapd and libc, it seems like the > only plausible way to fix this is to add functionality to nsswitch > which would allow it to use different configurations depending on the > identity of the process invoking getpwnam(3) or getgrnam(3). Does > anyone have opinions on how this ought to be implemented, or indeed > how it could be implemented securely? > > (As a side issue, the net/nss-pam-ldapd port completely ignores > account expiration dates. This bug is due to the fact that Linux has > this ships-in-the-night "shadow" mechanism, getspent(3), rather than > having it integrated in getpwent(3) like it should be, but the > ultimate upshot is that if you're using nss-pam-ldapd you can't rely > on shadowExpire attributes in the directory actually have an effect on > FreeBSD. I'll open a bugzilla issue about this.) > > -GAWollman > > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > -- Mike Kelly