Re: [ldapext] RFC2307, netgroups, DBIS

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

On 04/02/2015 23:06, Michael Ströder wrote:
> Mark R Bannister wrote:
>> [e-mail] 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).

So you've come up with a point solution for 'sudo' that would replace 
the need for sudo to use
netgroups, because you don't like netgroups.  Great for sudo, perhaps, 
but netgroups are of
generic use to multiple applications, whereas 'sudoRole' and 'sudoUser' 
are specific to sudo
only.  I don't think it's a great idea to replace a solution of generic 
applicability with one that
addresses the need of one specific use-case only.

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

I'm not the world's biggest fan of "service accounts", as users should 
be users in my mind, not
systems, but they're prevalent everywhere and I'm not going to solve 
that one.  However,
replacing another example of where netgroups fit nicely with one that 
requires every NFS client
to have its own authenticated user account is not practical in an 
enterprise environment with
80,000 user accounts already and 60,000 hosts.

NFSv4 has already solved the NFS authentication problem, and that 
requires nothing more
than the user who attempts to access the files having a valid Kerberos 
ticket.

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

Why not?  If everyone can login everywhere, your approach solves 
nothing?  It just adds an extra
layer of complexity and an extra hurdle to those attempting to 
troubleshoot issues.

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

If everyone can login everywhere, what NSS data is sensitive?

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

Yes but I'm trying to see how your approach can be made applicable for 
all, I don't see how it
could be put out for general use, and therefore I don't see how it can 
be compared with DBIS
or RFC2307, both of which are designed for wide adoption.

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

So is a lot of software, good and bad.

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

So what if I login one of your hosts and type 'getent passwd'.  What 
will I see?  Enough data
to do some 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.

At the cost of added complexity, a false sense of security unless you 
are very careful how
you design who can login to which hosts, and at best you've just shifted 
the target point
for hackers to the LDAP servers instead.

Best regards,
Mark.