[sudo-workers] Add support for DBIS netservices

[Phil Lello]

Looks like ldap is built-in to the sudoers plugin; I should add I'm a
lurker on this list, not a core sudo developer.

On Thu, Aug 20, 2015 at 9:36 AM, Bannister, Mark <
Mark.Bannister at morganstanley.com> wrote:

> Hi Phil,
>
>
>
> Ok, I didn’t know that, thanks.  So there are plugins that sudo can use to
> check policies in different ways.  That’s a good start.  Then yes I’d
> appreciate some advice on how to develop a plugin that would be accepted by
> core.
>
>
>
> Also bear in mind you have sudoers.ldap.  Architecturally does it make
> sense for sudo to have two different routes to LDAP communication?  If DBIS
> is handling all LDAP communication and caching for name services and
> autofs, how would we also make an option for sudo not to do its own LDAP
> communication but to use DBIS to fetch its sudoers file as well.  Is
> sudoers.ldap just another plugin that could also be substituted as easily
> for another?
>
>
>
> Thanks,
>
> Mark.
>
>
>
> *From:* Phil Lello [mailto:phil at dunlop-lello.uk]
> *Sent:* 19 August 2015 18:20
> *To:* Bannister, Mark (Enterprise Infrastructure)
> *Cc:* sudo-workers at sudo.ws
> *Subject:* Re: [sudo-workers] Add support for DBIS netservices
>
>
>
> Hi Mark,
>
> Is this not already achievable through the plugin API? If I read the code
> correctly, the sudoers file is processed by plugins/sudoers, and it's the
> exported functions that control access, e.g. the check_policy callback
> described at man sudo_plugin. Or is this more a conversation about defining
> a standard plugin that will be accepted by core?
>
> Phil
>
>
>
> On Wed, Aug 19, 2015 at 10:00 AM, Bannister, Mark <
> Mark.Bannister at morganstanley.com> wrote:
>
> Hi Todd et al,
>
> I'd like to start a discussion about adding support into sudo for a new
> feature that could be used instead of netgroups in a sudo configuration to
> determine who can run sudo and what they can do with it.  Let me explain.
>
> In 2013 I set out to replace RFC2307/RFC2307bis & NIS with a new
> collection of IETF internet drafts - to fix some problems in the original
> LDAP schema and also to add some new features.
>
> One of the new features in DBIS is called 'netservices' and the idea is to
> simplify the way that netgroups are used today.  I have seen several large
> enterprise environments over the past decade with tens of thousands of
> netgroups that are difficult to maintain and even more difficult to audit
> because netgroups are being used to represent not just groups of users or
> hosts (as they were originally intended) but also roles and permissions.
>
> The idea of netservices is to define the roles and permissions in a
> separate hierarchical model that is distinct to netgroups, leaving
> netgroups to do what they do best (grouping together users or hosts).
>
> If sudo were to support netservices, we would need a way in a sudo
> configuration of saying 'if the user has this netservice then they can run
> this task under sudo' or 'if the host has this netservice then sudo is
> allowed or disallowed'.
>
> DBIS is also a user-land caching daemon written in Python that is
> responsible for all communication with LDAP and caching of results, an NSS
> library that uses the caching daemon for looking up all NSS data in LDAP,
> and a set of APIs for external programs to make use of DBIS.  There is a
> Python and Perl API at present, and I am working on the C API at the
> moment, so I wanted to kick off this discussion to see what shape the C API
> should take to best suit sudo.
>
> You can read all about DBIS here: http://dbis.sf.net which also contains
> links to the related IETF internet drafts and provides download links so
> you can download it and kick the tyres.
> Netservices are defined specifically in section 3.2 here:
> http://www.ietf.org/id/draft-bannister-dbis-netgroup-05.txt
> I have a blog article all about netservices here:
> http://technicalprose.blogspot.co.uk/2013/08/dbis-introducing-netservices.html
>
> What do you think?  Do you have any questions?  I am aware that the
> documentation around the subject of netservices could do with some
> improvement, so I'd be interested to hear if you need more explanation.
>
> Best regards,
> Mark Bannister.
>
>
>
> ________________________________
>
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the
> opinions or views contained herein are not intended to be, and do not
> constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall
> Street Reform and Consumer Protection Act. If you have received this
> communication in error, please destroy all electronic and paper copies; do
> not disclose, use or act upon the information; and notify the sender
> immediately. Mistransmission is not intended to waive confidentiality or
> privilege. Morgan Stanley reserves the right, to the extent permitted under
> applicable law, to monitor electronic communications. This message is
> subject to terms available at the following link:
> http://www.morganstanley.com/disclaimers If you cannot access these
> links, please notify us by reply message and we will send the contents to
> you. By messaging with Morgan Stanley you consent to the foregoing.
> ____________________________________________________________
> sudo-workers mailing list <sudo-workers at sudo.ws>
> For list information, options, or to unsubscribe, visit:
> http://www.sudo.ws/mailman/listinfo/sudo-workers
>
>
>
>
> ------------------------------
>
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the
> opinions or views contained herein are not intended to be, and do not
> constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall
> Street Reform and Consumer Protection Act. If you have received this
> communication in error, please destroy all electronic and paper copies; do
> not disclose, use or act upon the information; and notify the sender
> immediately. Mistransmission is not intended to waive confidentiality or
> privilege. Morgan Stanley reserves the right, to the extent permitted under
> applicable law, to monitor electronic communications. This message is
> subject to terms available at the following link:
> http://www.morganstanley.com/disclaimers If you cannot access these
> links, please notify us by reply message and we will send the contents to
> you. By messaging with Morgan Stanley you consent to the foregoing.
>
>