Hi, James
I have a question just for interest.
The security context stores like
/etc/selinux/targeted/contexts/files/file_contexts.
But you are storeing the domain security label on libvirt specific XML.
Of course, this is good for libvirt POV.
Is it permitted for SELinux policy POV?
By the way, I want to see the further discussion of the Requirements.
> Requirements not yet addressed include:
Thanks
Atsushi SAKAI
James Morris <jmorris@xxxxxxxxx> wrote:
[snip]
> The domain security label configuration format is as follows:
>
> # virsh dumpxml sys1
> <domain>
> ....
> <seclabel model='selinux'>
> <label>system_u:system_r:virtd_t:s0</label>
> <policytype>targeted</policytype>
> </seclabel>
> </domain>
>
> It's possible to query the security label of a running domain via virsh:
>
> # virsh dominfo sys1
> Id: 1
> Name: sys1
> UUID: fa3c8e06-0877-2a08-06fd-f2479b7bacb4
> OS Type: hvm
> State: running
> CPU(s): 1
> CPU time: 11.4s
> Max memory: 524288 kB
> Used memory: 524288 kB
> Autostart: disable
> Security label: system_u:system_r:virtd_t:s0 (selinux/targeted/enforcing)
>
> The security label is deterimed via the new virDomainGetSecLabel() API
> method, which is transported over RPC to the backend driver (qemu in this
> case), and is entirely independent of the local security model, if any.
> e.g. this command could be run remotely from an entirely different
> platform: you just see what's happening on the remote system, as with
> other attributes of the domain.
>
> Feedback on the design thus far is sought before proceeding to more
> comprehensive integration.
>
> In particular, I'd be interested in any thoughts on the placement of the
> security labeling driver within libvirt, as this seems to be the most
> critical architectural issue (I've already refactored this aspect once).
>
> Currently, the idea is to attach the security labeling driver to the virt
> driver, rather than implement it independently as a top-level component as
> in the case of other types of drivers (e.g. storage). This is because
> process-based security labeling is highly dependent on the kind of
> virtualization in use, and may not make sense at all in some cases (e.g.
> when using a non-Linux hypervisor, or containers).
>
> In the case of qemu, a security labeling driver is added to qemud:
>
> @@ -63,6 +64,7 @@ struct qemud_driver {
> char *vncListen;
>
> virCapsPtr caps;
> + virSecLabelDriverPtr secLabelDriver;
> };
>
> and then initialized during qemud startup from qemudSecLabelInit().
>
> During initialization, any available security labeling drivers are probed,
> and the first one which thinks it should be used is installed. Top-level
> libvirt API calls are then dispatched to the active security labeling
> driver via the backend virt driver, as necessary.
>
> Note that the security labeling framework in this release is always
> built-in -- it can be made a compile-time option later if desired.
>
> Requirements not yet addressed include:
> - Labeling of resources and generally comprehensive labeling management
> - Automatic labeling (e.g. for the simple isolation use-case)
> - Integration of labeling support into higher-level management tools such
> as virt-manager
> - Integration with the audit subsystem to help with administration and
> debugging
> - Domain of interpretation (DOI) checking/translation
> - Python bindings
>
> As mentioned, the goal at this stage is to get feedback on the underlying
> design: comments welcome!
>
>
> - James
> --
> James Morris
> <jmorris@xxxxxxxxx>
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list