Re: [Xen-devel] [PATCH] libxl: assigned a default ssid_label (XSM label) to guests

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, May 14, 2015 at 01:32:04PM +0100, Ian Campbell wrote:
> On Thu, 2015-05-14 at 12:58 +0100, Wei Liu wrote:
> > On Thu, May 14, 2015 at 11:33:45AM +0100, 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.
> > > 
> > > 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.
> > > 
> > > I haven't done anything with the device model ssid.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > > Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
> > > Cc: Wei.Liu2@xxxxxxxxxx
> > > ---
> > >  docs/man/xl.cfg.pod.5      |    4 +++-
> > >  tools/libxl/libxl_create.c |   11 ++++++++---
> > >  2 files changed, 11 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> > > index 8e4154f..fcca1cc 100644
> > > --- a/docs/man/xl.cfg.pod.5
> > > +++ b/docs/man/xl.cfg.pod.5
> > > @@ -437,7 +437,9 @@ UUID will be generated.
> > >  
> > >  =item B<seclabel="LABEL">
> > >  
> > > -Assign an XSM security label to this domain.
> > > +Assign an XSM security label to this domain. By default a domain is
> > > +assigned the label B<system_u:system_r:domU_t>, which is defined in
> > > +the default policy.
> > >  
> > >  =item B<init_seclabel="LABEL">
> > >  
> > > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > > index f0da7dc..4dd2ec2 100644
> > > --- a/tools/libxl/libxl_create.c
> > > +++ b/tools/libxl/libxl_create.c
> > > @@ -42,6 +42,11 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
> > >      libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
> > >      libxl_defbool_setdefault(&c_info->driver_domain, false);
> > >  
> > > +    if (!c_info->ssid_label) {
> > > +        c_info->ssid_label = libxl__strdup(NOGC, 
> > > "system_u:system_r:domU_t");
> > > +        LOG(INFO, "Using default ssid_label: %s", c_info->ssid_label);
> > 
> > I don't think this is right. For one, the label you hardcoded here 
> > is defined in the policy we ship. It doesn't necessarily exist in the
> > policy that is loaded by system admin.
> 
> Personally I think that's fine, you either use the default, or you make
> sure your custom policy has a domU_t role (a very reasonable thing to
> have) or you specify something custom for every domain.
> 
> > Another thing, as Julien said, is that this generates a warning in Xen
> > that is not compiled with XSM support.
> > 
> > By definition if you don't label a domain, it should be labeled as
> > "unlabeled". We already do the right thing.
> 
> So how come osstest is failing? What should we do instead?
> 

AIUI current policy doesn't allow unlabeled domain to do certain things.
Maybe we can figure out a way to tune the policy to give certain
permissions to unlabeled domain.

This would need input from Daniel to know if it is achievable.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel