[libvirt] [PATCH 00/12] Fine grained access control for libvirt APIs

[Corey Bryant]

On 05/02/2012 07:44 AM, Daniel P. Berrange wrote:
> This is a repost of
>
>    https://www.redhat.com/archives/libvir-list/2012-January/msg00907.html
>
> which got no comments last time out.
>
> This series of patch is the minimal required to get a working proof
> of concept implementation of fine grained access control in libvirt.
>
> This demonstrates
>
>   - Obtaining a client identity from a socket
>   - Ensuring RPC calls are executed with the correct identity sset
>   - A policykit access driver that checks based on access vector alone
>   - A SELinux access driver that checks based on access vector + object
>   - A set of hooks in the QEMU driver to protect virDomainObjPtr access
>
> Things that are not done
>
>   - APIs for changing the real/effective identity post-connect
>   - A simple RBAC access driver for doing (Access vector, object)
>     checks
>   - SELinux policy for the SELinux driver
>   - Access control hooks on all other QEMU driver methods
>   - Access control hooks in LXC, UML, other libvirtd side drivers
>   - Access control hooks in storage, network, interface, etc drivers
>   - Document WTF todo to propagate SELinux contexts across TCP
>     sockets using IPSec. Any hints welcome...
>   - Lots more I can't think of right now

Does it make sense to have an AppArmor driver too?

-- 
Regards,
Corey

>
> I should note that the policykit driver is mostly useless because it
> is unable to let you do checks on anything other than permission name
> and UNIX process ID at this time. So what I've implemented with the
> polkit driver is really little more than a slightly more fine grained
> version of the VIR_CONNECT_RO flag. In theory it is supposed to be
> extendable to allow other types of identity information besides
> the process ID, and to include some kind of object identiers in
> the permission check, but no one seems to be attacking this.
>
> So I expect the simple RBAC driver to be the most used one in the
> common case usage of libvirt, and of course the SELinux driver.
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
>