From: Paul Moore <paul.moore@hp.com>
To: James Morris <jmorris@namei.org>
Cc: Daniel J Walsh <dwalsh@redhat.com>,
libvir-list@redhat.com,
"Daniel P. Berrange" <berrange@redhat.com>,
Daniel Veillard <veillard@redhat.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
selinux@tycho.nsa.gov
Subject: Re: [RFC] sVirt v0.10 - initial prototype
Date: Thu, 23 Oct 2008 08:05:39 -0400 [thread overview]
Message-ID: <200810230805.39558.paul.moore@hp.com> (raw)
In-Reply-To: <alpine.LRH.1.10.0810221858300.19361@tundra.namei.org>
On Wednesday 22 October 2008 5:23:45 am James Morris wrote:
> On Tue, 21 Oct 2008, Daniel J Walsh wrote:
> > Why do we care about the policy type? Policy type is a fairly
> > meaningless object. If you are trying to figure out if the host
> > machine is valid to run a virtual machine you should just check
> > whether the type is valid on the machine, That way if I define
> > minimum policy with virt support on one host and targeted policy
> > with virt support on another machine, both would work.
>
> We need a way to indicate how to interpret the meaning of labels,
> which may vary depending on how policy has been implemented and
> deployed within a specific administrative boundary. Keep in mind
> also that this API needs to be useable with non-SELinux security
> schemes, although, in any case, just because a label is technically
> valid on a system, doesn't mean that the meaning is understood. e.g.
> "virt_image_t:s0" on a targeted system could mean something radically
> different to "virt_image_t:s0" on an MLS system, where, say, "s0"
> might mean "top secret" instead of "nothing".
>
> Perhaps we should call this element "doi" (Domain of Interpretation)
> instead of "policytype", in keeping with existing similar security
> labeling, and not tied in name to the SELinux polictype configuration
> variable.
>
> I thought the SELinux policytype in this case would be a useful
> starting point for the DOI, although the truth is that this needs to
> be entirely administratively managed. We can't predict where
> administrative security boundaries will be or how the user will
> represent them. Possibile DOI schemes include domain name, policy
> package+version names, existing kerberos realms etc.
I like the concept of a DOI field instead of policy type; considering
the portability of guest images this seems like a good solution based
on the relative success of DOIs in other distributed applications.
However, may I suggest that instead of representing the DOI as a string
we use a 32bit integer? I know that may sound a bit odd, but in the
networking world most DOI values are represented as integers and when
security labels are involved they tend to be 32bits. I understand that
using a plain integer is much more abstract than a human readable
string but it should make it easier to leverage existing and future*
DOI frameworks.
*An informal group/list just formed to start discussing DOI management
issues such as DOI formats, negotiation and translation.
--
paul moore
linux @ hp
--
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:[~2008-10-23 12:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-21 2:06 [RFC] sVirt v0.10 - initial prototype James Morris
2008-10-21 13:57 ` Daniel J Walsh
2008-10-21 16:22 ` Daniel P. Berrange
2008-10-21 17:50 ` Daniel J Walsh
2008-10-22 9:51 ` Daniel P. Berrange
2008-10-22 9:50 ` James Morris
2008-10-22 10:03 ` Daniel P. Berrange
2008-10-22 10:05 ` James Morris
2008-10-29 21:51 ` James Morris
2008-10-22 9:23 ` James Morris
2008-10-23 12:05 ` Paul Moore [this message]
2008-10-28 21:42 ` James Morris
2008-10-28 22:17 ` Paul Moore
2008-10-29 14:40 ` David P. Quigley
2008-10-21 17:17 ` Daniel P. Berrange
2008-10-22 10:01 ` James Morris
2008-10-30 9:40 ` [libvirt] " Atsushi SAKAI
2008-10-30 19:18 ` Daniel J Walsh
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=200810230805.39558.paul.moore@hp.com \
--to=paul.moore@hp.com \
--cc=berrange@redhat.com \
--cc=dwalsh@redhat.com \
--cc=jmorris@namei.org \
--cc=libvir-list@redhat.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=veillard@redhat.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.