From: Ian Campbell <ian.campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [PATCH] libxl: assigned a default ssid_label (XSM label) to guests
Date: Thu, 14 May 2015 13:32:04 +0100 [thread overview]
Message-ID: <1431606724.13579.65.camel@citrix.com> (raw)
In-Reply-To: <20150514115859.GA19352@zion.uk.xensource.com>
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@citrix.com>
> > Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > Cc: Wei.Liu2@citrix.com
> > ---
> > 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?
Ian.
next prev parent reply other threads:[~2015-05-14 12:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 10:33 [PATCH] libxl: assigned a default ssid_label (XSM label) to guests Ian Campbell
2015-05-14 11:21 ` Julien Grall
2015-05-14 11:54 ` Ian Campbell
2015-05-14 14:18 ` Julien Grall
2015-05-14 23:09 ` Daniel De Graaf
2015-05-15 9:39 ` Ian Campbell
2015-05-15 17:09 ` Daniel De Graaf
2015-05-18 10:56 ` Ian Campbell
2015-05-18 12:38 ` Ian Campbell
2015-05-18 22:37 ` Daniel De Graaf
2015-05-19 10:43 ` Ian Campbell
2015-05-14 11:58 ` Wei Liu
2015-05-14 12:32 ` Ian Campbell [this message]
2015-05-14 12:39 ` Wei Liu
2015-05-14 14:05 ` Julien Grall
2015-05-14 14:11 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1431606724.13579.65.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=ian.jackson@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).