[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[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 namei org>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]