| Newsgroups |
gmane.ietf.ldapext |
| Message-ID |
<[email protected]> |
(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.
_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext