On Thu, Nov 24, 2011 at 02:08:31PM +0800, Daniel Veillard wrote: > On Wed, Nov 23, 2011 at 12:27:27PM -0500, Dave Allan wrote: > > On Wed, Nov 23, 2011 at 06:17:46PM +0100, Michal Privoznik wrote: > > > Hi all, > > > > > > I'd like to implement this new feature for libvirt. However, I think we > > > should settle down on design first. My biggest concern is choosing the > > > right level on on which ACLs will be implemented. Should be interested > > > only in (user, API), or with more granularity (user, API, API's parameters)? > > > Or should we take the RBAC path? > > > How should we even identify and authorize users? > > > > > > My initial though is to create framework which can be used then to > > > implement ACLs on any level we want. > > > > My $.02 is that this has the potential to be such a huge project that > > we need to come up with a design that lets us bite off as much as we > > want at one time, leaving the rest of libvirt's functionality > > operating as it always has. So, for example, we could start by > > creating an ACL that would let a particular user boot and shutdown but > > not edit a VM; later when we wanted to let particular users connect to > > the VM's console, we could implement that, and so on. It needs to be > > done in a consistent way so that future additions are clearly slotted > > into the existing design. > > I tend to agree, I think like for the security module, we should provide > an access control driver API with exhaustive parameters, but as a first > step implement a simple user based driver. We just need to make sure > that it would allow to implement a full RBAC kind of driver. > It seems to me that the driver just need to plug in the API entry > points, i.e. mostly libvirt.c. > I would probably not pass all APIs parameters at the API level > but some function ID, and main arguments: > - connection > - domain > - network > - interface > - pool > - vol > - device > - snapshot > - secret > - stream > - ... > - and some kind of string (could be used for xml, uuid, device path, or > migration URI for example) > > The first use of that driver could be to implemenent the read-only > mode of connections internally. Might indicate that being able to > stack multiple access control driver as an interesting feature (i.e. > how to finer restrict read-only mode with extra rules). > > I think a lot of the code in the driver front-end should be fairly > mechanical ... dunno if we should generate it from the API description > though, just an idea. I'm afraid that kind of design will not work. You can't do access control based on the data in the libvirt API entry point frontend. It has not been validated by the driver, so it is not secure to trust it. Access controls checks have to be done at time of use, or as close as is possible, which means they have to be put into the internals of each driver. See my first mail for more details. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list