Re: RFC2307, netgroups, DBIS

Mark R Bannister wrote:
> On 04/02/2015 23:06, Michael Ströder wrote:
>> 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).
> 
> So you've come up with a point solution for 'sudo' that would replace the
> need for sudo to use netgroups,

No, it's generally applicable.

> to have its own authenticated user account is not practical in an
> enterprise environment with 80,000 user accounts already and 60,000 hosts.

It is indeed practical. BTW: This is basically what's already done when adding
servers and workstations in MS AD with Kerberos used as authc mech.

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

AFAICS it also requires the servers to have a Kerberos keytab with their
service principal's key(s).  Others with more in-depth Kerberos knowledge
might elaborate on that.  So this model fits my approach quite nicely. :-)

>>> 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? 
> [..]
>>> However, the NSS data isn't particularly sensitive anyway,
>> I disagree.
> 
> If everyone can login everywhere, what NSS data is sensitive?

Your assumption that "everyone can login everywhere" is wrong.

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

If you are root on a system you will see this partial directory data to do
social engineering:

1. getent group: the user groups assigned as visible for this server group

2. getent passwd: all member users of the visible user groups (see 1.).

3. sudo -l: You can discover who can use which sudoers rules visible for this
server group

Admins with access to very sensitive systems are adviced to have separate
accounts (role separation).

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

But the complexity is implemented *centrally* at the LDAP server's side.
Furthermore the server-side visibility rules are even then enforced when a NSS
client got hacked and re-configured by an attacker.

Which both is a huge gain over having to tweak *all* PAM/NSS clients to do the
right thing.

Note that only LDAP entries are added/modified.  The ACLs working their way
through the references are *static* configuration.

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

Yes, similar like DBIS this is a frame-work.  The responsible system admins
have to be sufficiently eager to make use of the authorization mechanisms
provided.  The admins have to carefully craft an access control policy by
defining server groups and their relationship to user groups and sudo rules, etc.

Admins who just want an easy one-size-fits-it-all security policy are
definitely not the target audience of any serious access control scheme (and
IMHO should be kicked out of business in the long run).

Ciao, Michael.

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