On Fri, Aug 29, 2008 at 05:13:23PM +1000, James Morris wrote: > In the simplest case, we'll just be wanting to ensure that domains are > running with distinct labels for separation purposes, so that concept may > be possible to convey during migration. > > As for specific labels (e.g. "privileged", "company-confidential" etc.), > this is a general problem to be solved for distributed MAC security, and > we would not expect to solve it here in the first iteration. There's a > term used in this area called Domain of Interpretation (DOI), which is > essentially label metatdata used to interpret/translated labels between > systems. It's something that can be added to the XML if/when needed, but > we don't need it now. Can I add that there's a very specific use case that I've been asked about several times. I think it's worth bearing it in mind. The "ISP scenario" ------------------ An ISP is running a hosting facility where they supply Xen guests to customers. Each physical host runs many guests, and clearly to maximize revenue guests belonging to many different customers may be running on the same single host. The host is running RHEL, with a management interface offered through libvirtd. The ISP wants to offer customers a facility where they can connect to the host libvirtd and manage any guests that they own. They must be able to monitor, start, stop, etc. their own guests. However they must not be able to interfere with guests owned by other customers. (It's an open question whether they can even *see* guests owned by other customers -- I'm guessing that most ISPs would wish to prevent this as well). - - - Whatever we do should allow the ISP scenario. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list