Re: RFC2307, netgroups, DBIS

Mark R Bannister wrote:
> [email protected] wrote:
>> Mark R Bannister wrote:
>>> 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.

The server only sees 'sudoRole' entries assigned as visible for its particular
server/host/service group(s). Which particular command a user can execute is
indeed subject to fine-grained control by sudo on the client (based on
attribute 'sudoUser' which with my approach is restricted to only referencing
user groups).

Similar file system permissions/ACLs are evaluated locally, but based on the
limited subset of visible user groups.

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

In my model such a NFS client host would be also simply an authenticated
(system) user and member of user groups. The NFS server only sees user groups
assigned as visible for its particular server/host/service group. And
furthermore it only sees the members of those user groups (NFS clients in this
example).

Yes, of course: No IP-based authentication!

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

Yes. But not with my approach.

> However, the NSS data isn't particularly sensitive anyway,

I disagree.

> and quite often the LDAP directories are open for anyone with a network 
> device to query over port 389 anyway,

Yes in general, but not with my approach. ;-}

> so I haven't worked in an organisation yet where applying server-side ACLs
> to NSS maps would actually be of any practical use.

Well, this system is in production use.  :-)

> What was the use-case you saw for it?

Role separation with separate credentials (especially passwords for sudo
access), and paranoid protection of information I consider sensitive because
it could be used to plan next steps (e.g. social engineering).

And furthermore you can keep the client configuration and map evaluation very
simple because the visibility of users and user groups is constrained by
access control based on server/host/service group membership of the NSS client.

Ciao, Michael.

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext