[sudo-workers] Policy Plugins

[Michael]

Yup, MFA was a bad example.  For my project I need three policy plugins simultaneously:

1.  First one checks a signature in the target binary and if it is signed & valid allows the command to be run as root.  I might extend this to use certificates as the certificates can then carry constraints and allow further delegation of sudo management etc.
2.  Second one checks a remote enterprise repository for rules to see if the command is allowed.  It will keep a local expiring cache, but the remote repo could be offline.
3.  Last one is a break-glass local sudoers policy in case of network issues.

My first thought was to do the daisy chaining myself - so my policy plugin calls exported functions from another policy plugin and then eventually calls the original suoders policy plugin.  It could enable multiple policies without impacting the core.  I don't like the idea of a plugin that then provides child plugins and eventually (I suspect) my API would support extensions that aren't in the core and it all starts to diverge.  

Anyway, I've been playing with actually having multiple plugins enabled and have included an "alpha" patch (attached).  It isn't ready for a couple of reasons, but is good to have a look/play/check behaviors etc.  Notes:

a. Enables multiple policy plugins (implementation is the same as for io_plugins)
b. Implements a "first plugin to allow the command" strategy, but also allows plugins to return from check_policy() with a DENY which stops early.
c. Logical behavior for different MODEs (like VERSION, INVALIDATE, KILL, LIST etc) and changing some errors into warnings
d. Changed the sample_plugin to include "test" to approve command and "deny" to reject as valid passwords
e. Need to understand how debug_files is used and make sure the behavior is correct
f. Need to check how hooks are implemented and make sure the behavior is correct
g.  Need to test how MODE_EDIT behaves with multiple policies that support it

Another idea I've been asked about is the ability to go look up in a ticketing system if an approved incident or change ticket exists.  The ticket would have to be assigned to the invoker of sudo and be running on a server the ticket is raised against.  That is a cool idea and something that other people might benefit from - but, it is hardly something to include in the core of SUDO.  So, my initial response to that was I'll call a Python script and you can work it out from there.

I am also starting to think policy plugins will need to declare external requirements which might be met from another policy/authoriser plugin before a command is allowed (e.g. NEEDS_PASSWORD, NEEDS_TICKET, NEEDS_DIGITAL_SIGNARTURE).

Even if the new API splits out policy rules and approval then in my scenario I could have a sudoers rule allowing running a command as root without password but NEEDS_TICKET.  An approval plugin could then go away and check that.  If it fails then sudoers should carry on as I might also have a break-glass rule.  That would work.  But for a remote repository of sudo rules then this would not work.. :[

Big question for me is do I support multiple policy plugins by writing a current version compatible policy plugin that then supports multiple child policy plugins, or write it into the core of SUDO.  Happy to knock ideas around and try things out.


Mike

________________________________________
From: Todd C. Miller <Todd.Miller at courtesan.com>
Sent: 13 May 2016 11:59
To: Michael
Cc: sudo-workers at sudo.ws
Subject: Re: [sudo-workers] Policy Plugins

The reason that only a single policy plugin is supported is that
combining multiple disparate security policies in a meaningful way
is hard to do.  How would you even analyze such a composite policy?

I don't think multi-factor authentication is a good reason to support
this, that is the job of things like PAM.

What I had been contemplating for a revamped plugin API is adding
approval plugins.  These would not grant privileges and could only
be used to deny a command that was allowed by the policy plugin.

Possible uses include:

1. Local time of day restrictions.

2. Explicit approval requirements from a more senior admin, potentially
   requiring the senior admin to sign-off on the command via XMPP
   or some other method.

 - todd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiple-policy-plugins.patch
Type: application/octet-stream
Size: 20068 bytes
Desc: multiple-policy-plugins.patch
URL: <https://www.sudo.ws/pipermail/sudo-workers/attachments/20160516/35876252/attachment.obj>