From: Stephen Smalley <sds@tycho.nsa.gov>
To: Daniel J Walsh <dwalsh@redhat.com>
Cc: Ramon de Carvalho Valle <rcvalle@linux.vnet.ibm.com>,
SELinux@tycho.nsa.gov
Subject: Re: SELinux mixed/virtualisation policy
Date: Mon, 11 Apr 2011 12:33:03 -0400 [thread overview]
Message-ID: <1302539583.7338.43.camel@moss-pluto> (raw)
In-Reply-To: <4DA31D2D.9060409@redhat.com>
On Mon, 2011-04-11 at 11:24 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/11/2011 09:40 AM, Stephen Smalley wrote:
> > On Sun, 2011-04-10 at 14:12 -0300, Ramon de Carvalho Valle wrote:
> >> However, I and Dan Walsh (who kindly informed me about libvirt) both
> >> agree that dynamic labeling is more secure than manual labeling using
> >> MLS policy, for virtual machine environments.
> >
> > Can you elaborate on what your concern is there? If it is merely that
> > two VMs at the same level are not isolated via the MLS policy, then that
> > isn't a MLS concern, and you could use TE instead to isolate the VMs of
> > the same level.
> >
> I think what he is after is the convenience of dynamic labeling, for
> isolation. Yes he could create new types for each instance, which every
> virtual machine would need, this could cause a potential explosion in
> the number of types and would be subject to failure. It would be
> putting a large onus on the Admin to manage all of these types. The
> real beauty of dynamic labeling is that it just works.
The types could be automatically generated from a template, and managed
by libvirt in much the same way it presently manages categories.
In any event, he can do the same thing by use of categories rather than
introducing an incomparable set of sensitivities, and that wouldn't
require any changes to the policy toolchain or kernel security server.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2011-04-11 16:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-10 17:12 SELinux mixed/virtualisation policy Ramon de Carvalho Valle
2011-04-11 13:40 ` Stephen Smalley
2011-04-11 15:24 ` Daniel J Walsh
2011-04-11 16:33 ` Stephen Smalley [this message]
2011-04-11 17:14 ` Ramon de Carvalho Valle
2011-04-11 17:59 ` Daniel J Walsh
2011-04-11 20:44 ` chanson
2011-04-11 21:03 ` Daniel J Walsh
2011-04-12 12:50 ` Stephen Smalley
2011-04-13 10:24 ` Ramon de Carvalho Valle
2011-04-13 12:19 ` Stephen Smalley
2011-04-13 13:03 ` Ramon de Carvalho Valle
2011-04-13 13:34 ` Russell Coker
2011-04-13 13:51 ` Stephen Smalley
2011-04-13 14:01 ` Daniel J Walsh
2011-04-13 18:33 ` Ramon de Carvalho Valle
2011-04-13 18:32 ` Ramon de Carvalho Valle
2011-04-13 19:09 ` Daniel J Walsh
2011-04-11 14:20 ` Russell Coker
2011-04-11 17:26 ` Ramon de Carvalho Valle
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=1302539583.7338.43.camel@moss-pluto \
--to=sds@tycho.nsa.gov \
--cc=SELinux@tycho.nsa.gov \
--cc=dwalsh@redhat.com \
--cc=rcvalle@linux.vnet.ibm.com \
/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.