On Thu, 2015-05-14 at 12:21 +0100, Julien Grall wrote: > Hi Ian, > > On 14/05/15 11:33, Ian Campbell wrote: > > system_u:system_r:domU_t is defined in the default policy and makes as > > much sense as anything for a default. > > So you rule out the possibility to run an unlabelled domain? This is > possible if the policy explicitly authorized it. That's a significant > change in the libxl behavior.
I didn't realise this was a possibility, wouldn't such a domain be system_u:system_r:unlabeled_t> or something? Note that this won't override a label which is just '' (i.e. an empty string rather than NULL). I don't know if that results in the behaviour you want. When this was discussed before (in a conversation Wei started, but which I can't find, maybe it was IRC rather than email) it seemed that consensus was that by default things should Just Work as if XSM weren't disabled, which is what I've implemented here. > IHMO, having a default policy doesn't mean libxl should set a default > ssid to make XSM transparent to the user. > > The explicit ssid makes clear that the guest is using a ssid foo and if > it's not provided then it will fail to boot. > > Setting a default value may hide a bigger issue and take the wrong > policy the user forgot to set up an ssid. Does domU_t really have so many privileges that this is an issue? I'd expect it to be almost totally privilegeless apart from things which any domU needs. The benefits of XSM seem to mainly apply to the various service domains. Daniel, do you have an opinion here? > > > This change required moving the call to domain_create_info_setdefault > > to be before the ssid_label is translated into ssidref, which also > > moves it before some other stuff which consumes things from c_info, > > which is correct since setdefault should always be called first. Apart > > from the SSID handling there should be no functional change (since > > setdefault doesn't actually act on anything which that other stuff > > uses). > > > > There is no need to set exec_ssid_label since the default is to leave > > the domain using the ssid_label after build. > > By setting a ssid label, libxl will print a new warning on Xen not built > with XSM which will confuse the user: > > libxl: warning: libxl_create.c:813:initiate_domain_create: XSM Disabled: > init_seclabel not supported Ah, I didn't try that case. I'll see if I can work out a way to suppress that warning. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
