[libvirt] Re: [RFC] sVirt v0.10 - initial prototype
On Tue, 21 Oct 2008, Daniel P. Berrange wrote:
As I mentioned in my reply to Dan Walsh's comments, I thing that
the
policy type & its state (disabled, permissive, enforcing) is really a
property of the host, rather than the VM, and so should live in the
host capabilities XML document.
I think we need to differentiate between what the host is capable of
supporting (e.g. multiple virt schemes with different security models, or
even emulating/translating other security models), and what the current
label on the domain actually is. In the latter case, we need to bind the
DOI, enforcing state and security model to the domain security label.
That all makes sense to me - you'll also likely need to expose
the
hypervisor driver's active security driver, to the storage & network
drivers. For that I reckon extending the 'virDriverPtr' struct to
add a internal only method
virSecLabelDriverPtr (*getSecLabelDriver)(void);
would be a suitable approach. This would avoid the storage/network
drivers needing to know about the internal state of the HV driver.
Ok, I need to investigate this further.
> +typedef struct _virDomainSecLabel {
> + char model[VIR_SECLABEL_MODEL_BUFLEN]; /* name of security
labeling model */
> + char label[VIR_SECLABEL_LABEL_BUFLEN]; /* security label string
*/
> + char policytype[VIR_SECLABEL_POLICYTYPE_BUFLEN]; /* policy type */
> + int enforcing; /* 1 if security policy is
being enforced for domain */
> +} virDomainSecLabel;
The policytype/model would seem redundant here as per-host attributes ?
As mentioned, I think we need to differentiate host capabilities from
specific security labeling state for a domain on that host.
I guess since SELinux gained ability to specify that individual
security
domains are permissive, we do arguably still need an explicit flag
'enforcing' flag here, independantly of the global per-host 'enforcing'
vs 'permissive' flag.
Yep.
- James
--
James Morris
<jmorris(a)namei.org>