All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: saag@ietf.org
Cc: nfsv4@ietf.org, labeled-nfs@linux-nfs.org,
	nfs-discuss@opensolaris.org, selinux@tycho.nsa.gov
Subject: Common labeled security (comment on CALIPSO, labeled NFSv4)
Date: Thu, 2 Apr 2009 10:44:02 -0500	[thread overview]
Message-ID: <20090402154402.GM1500@Sun.COM> (raw)

Over at the NFSv4 WG we've been having a discussion of a labeled NFSv4
proposal.  [Note: NFSv4 WG and others cc'ed, Reply-To: set to SAAG.]

An interop issue has arisen that we believe applies equally to CALIPSO
(draft-stjohns-sipso-11.txt)and requires input from the IETF security
area.

The issue is: how do do nodes in a labeled network/application know if
they agree on a common labeled security policy for a given DOI?

Agreeing on a DOI is accomplished easily enough -- that's not an issue.
Agreeing on what a given numeric sensitivity level or compartment bit
means in a given DOI is quite another.  Without a solution to this we're
left with out-of-band agreement, which leaves interop in a lurch.

I think we need a generic MLS and DTE labeled security policy document
format that allows a DOI to define the names and numeric assignments of
sensitivity levels, compartments, etcetera.

We also need a way for nodes to agree that they have the same policy for
a given DOI, or that they agree on a common subset of a DOI's policy.

This last problem can be solved by use of a labeled security policy URI
scheme that includes a version number (+ a requirement that changes be
in the form of additions and obsolescence of old assignments, but not
removals).

To recap: I think we need a) a common MLS and DTE labeled security
policy document format, b) a labeled security policy URI scheme to refer
to such documents by.

Given (a) and (b) NFSv4.x clients and servers would only have to
exchange {DOI #, policy URI} tuples to determine whether they agree on a
common policy.

Note that CALIPSO describes how to encode and compare MLS labels on the
wire, but it does not describe how nodes agree on the meaning of
particular sensitivity levels or compartments.  Therefore CALIPSO is
going to have much the same problem as NFSv4.

Nico
-- 

--
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.

             reply	other threads:[~2009-04-02 16:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-02 15:44 Nicolas Williams [this message]
     [not found] ` <FAD1CF17F2A45B43ADE04E140BA83D48A9FF82@scygexch1.cygnacom.com>
2009-04-03 15:42   ` [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Nicolas Williams
     [not found]     ` <FAD1CF17F2A45B43ADE04E140BA83D48A9FF9E@scygexch1.cygnacom.com>
2009-04-03 17:36       ` Nicolas Williams
     [not found]         ` <FAD1CF17F2A45B43ADE04E140BA83D48A9FFAF@scygexch1.cygnacom.com>
2009-04-03 19:18           ` Nicolas Williams
     [not found]             ` <FAD1CF17F2A45B43ADE04E140BA83D48A9FFBE@scygexch1.cygnacom.com>
2009-04-03 19:57               ` Nicolas Williams
     [not found]                 ` <49D80922.9050700@ieca.com>
2009-04-06 15:11                   ` Nicolas Williams
     [not found]   ` <20090403164522.DEA9A9A4739@odin.smetech.net>
2009-04-03 16:51     ` Nicolas Williams
     [not found]     ` <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com>
     [not found]       ` <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE0@scygexch1.cygnacom.com>
     [not found]         ` <B8FB99E8-17AA-4D4B-A309-8AF79838A304@Isode.com>
     [not found]           ` <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE9@scygexch1.cygnacom.com>
2009-04-06 15:16             ` Nicolas Williams
     [not found]               ` <FAD1CF17F2A45B43ADE04E140BA83D48AA0032@scygexch1.cygnacom.com>
2009-04-06 16:22                 ` Nicolas Williams

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=20090402154402.GM1500@Sun.COM \
    --to=nicolas.williams@sun.com \
    --cc=labeled-nfs@linux-nfs.org \
    --cc=nfs-discuss@opensolaris.org \
    --cc=nfsv4@ietf.org \
    --cc=saag@ietf.org \
    --cc=selinux@tycho.nsa.gov \
    /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.