All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Julien Grall <julien.grall@citrix.com>,
	wei.liu2@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [PATCH] libxl: assigned a default ssid_label (XSM label) to guests
Date: Mon, 18 May 2015 11:56:33 +0100	[thread overview]
Message-ID: <1431946593.4944.36.camel@citrix.com> (raw)
In-Reply-To: <55562846.8030703@tycho.nsa.gov>

On Fri, 2015-05-15 at 13:09 -0400, Daniel De Graaf wrote:
> > I'd be inclined to go the other way and either have a default ssid for
> > the DM or to fail if one isn't given (the latter would probably happen
> > anyway due to enforcement?).
> 
> Yes, it would probably fail at xc_domain_set_target in enforcing mode.
> 
> > Sounds like the default ssidref should be either ~= domU_t of domHVM_t
> > depending on the type of domain? (domU_t is really domPV_t?)
> 
> The domU_t type also works for HVM domains with the device model in dom0.
> 
> Looking at the problem again, I think a second initial SID for the device
> model would be preferable, removing domHVM_t completely.  There are already
> other example types in the policy for domains that do not use a device model
> (isolated_domU_t is probably the best example), and the result more closely
> matches the permissions used in the hypervisor without XSM enabled.

I'm aroundabout half sure what you are proposing here, but I trust it
makes sense ;-).

I think for now I will investigate using a default ssid for all domains,
which AIUI from above will work out of the box with PV guests and HVM
ones which have qemu in dom0.

For the stubdom case I think I'll leave it to you to change the default
policy, at which point I'll be happy to extend things to a default ssid
for stubdom too.

Ian.

  reply	other threads:[~2015-05-18 10:56 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 [this message]
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
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=1431946593.4944.36.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien.grall@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.