Re: [ldapext] RFC2307, netgroups, DBIS

[Mark R Bannister <[e-mail]>]

On 02/02/2015 10:20, [e-mail] (POP3) wrote:
> (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.

Generically, application roles.  A specific example: sudo, where sudo 
rules are enabled for users based on netgroup membership.  The LDAP 
server does not know the user requesting sudo access, only the client 
system knows that, so server-side ACLs are not going to help.

I do need to give a second example, because the first is specific to 
users.  Here is one specific to hosts: NFS, where an NFS server might 
grant read-only access to every host on the network except for those 
that are members of a specific netgroup, which get read-write access.  
The NFS server needs to know when a client request comes in whether this 
host is a member of the netgroup that grants read-write access or not, 
and this cannot be implemented by server-side ACLs, because only the NFS 
server knows the identity of the client requesting access to the fileshare.

>
>>> 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.

In the deployments I see, typically every user can login to every host, 
and any application could run anywhere, therefore any compromised 
machine will of course yield all NSS data.  However, the NSS data isn't 
particularly sensitive anyway, and quite often the LDAP directories are 
open for anyone with a network device to query over port 389 anyway, so 
I haven't worked in an organisation yet where applying server-side ACLs 
to NSS maps would actually be of any practical use.

What was the use-case you saw for it?

>
>> 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.
>
>
I wasn't suggesting that different users get different filtered views of 
the NSS maps.  They're open for all to see.  They should, however, 
continue to be used to determine application rights and roles on a 
client, as they do today, which server-side ACLs cannot replace.

Best regards,
Mark.