All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarrett Lu <Jarrett.Lu@Sun.COM>
To: Nicolas Williams <Nicolas.Williams@Sun.COM>
Cc: labeled-nfs@linux-nfs.org, nfs-discuss@opensolaris.org,
	selinux@tycho.nsa.gov, nfsv4@ietf.org
Subject: Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF	website
Date: Fri, 27 Mar 2009 11:56:41 -0700	[thread overview]
Message-ID: <49CD2169.3080209@sun.com> (raw)
In-Reply-To: <20090327172632.GA9992@Sun.COM>

Nicolas Williams wrote:
> On Fri, Mar 27, 2009 at 10:03:35AM -0700, Jarrett Lu wrote:
>   
>> I agree with your statements on TE vs. MLS/BLP. The problem we try to 
>> solve is whether a DOI field + an opaque string is sufficient to solve 
>> the interoperability problem. My opinion is that it's insufficient as it 
>> doesn't take the "how to interpret MAC attribute agreement among all 
>> communicating peers" into account. The current proposal seems to assume 
>> when a node sees a DOI value of 5, it knows how to interpret the opaque 
>> field. This may not be true. In MLS, one also needs to know which agreed 
>> upon label encoding file to use in order to interpret label in the 
>> opaque filed. I believe the same is true for TE -- one needs to know the 
>> security policy being used in order to correctly interpret security 
>> context string in the opaque field. DOI + opaque field doesn't say which 
>> label encoding scheme or which security policy.
>>     
>
> What would you add or remove on the wire to solve this problem?  My
> guess: a registry of per-DOI rules, like CALIPSO does.  I don't think a
> registry of DOI rules is strictly necessary for NFS (though I can see
> how it helps in the case of IP), but I certainly don't object.
>   

I don't yet see a good way to solve this problem using bits on the wire. 
The agreement on what label encodings or security policy to use seems 
better solved in an out of band manner. For example, on a (secure) 
website, you can say "download this label encoding file or configure 
your MAC system with this policy and use DOI number 5. Then we can talk".

BTW, CALIPSO with IP module has the same issue. While the spec talks a 
lot about how a CALIPSO  system should behave, CALIPSO can't tell its 
peers to use a particular label encoding. That's done outside CALIPSO.

I believe it's still worthwhile to request adding a DOI + an opaque 
field in NFSv4 protocol. The spec should be clear that other 
arrangements need to be made before interoperability can take place.

Once we decouple DOI from how the opaque field should be interpreted, 
it's possible for NFSv4 to use CALIPSO DOI. For example, DOD can reserve 
DOI 1000 through 1005. It can then decide that 1000 is only used by MLS 
systems with a particular label encoding; and 1004 is for TE systems 
configured with a particular secular security policy. As long as all 
systems using these DOIs agreeing to that, they can communicate with 
each other. But the agreement happens outside NFSv4 protocol itself. I 
understand this is different from the public internet where all you need 
is an IP address to communicate. But this is how MAC systems are used, I 
believe.

CALIPSO spec has considerations in how routers can support DOI and MLS 
labels. I don't believe that affects or harms NFSv4 in anyway, as 
routers won't look at NFSv4 stuff.


Jarrett


--
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-03-27 18:56 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-22 19:16 New MAC label support Internet Draft posted to IETF website David P. Quigley
     [not found] ` <54E18340-3542-4AB4-843E-E92A67B709A7@storspeed.com>
2009-01-23 17:47   ` [nfsv4] " Peter Staubach
2009-01-23 21:59     ` Glenn Faden
2009-01-23 19:07   ` [Labeled-nfs] " Kevin L. Smith
     [not found]   ` <33B70CB9-5260-419A-98CF-94847F829570@nokia.com>
2009-01-28  1:17     ` Jarrett Lu
2009-02-09 22:24 ` Peter Staubach
2009-02-11 23:47   ` David P. Quigley
2009-02-12  1:07     ` [Labeled-nfs] " James Morris
2009-02-12 15:36       ` [nfsv4] " Nicolas Williams
2009-02-12 20:00         ` David P. Quigley
2009-02-12 20:11           ` Nicolas Williams
2009-02-17 16:50             ` David P. Quigley
2009-02-17 17:00               ` Nicolas Williams
2009-02-12 19:45       ` David P. Quigley
2009-02-12 15:22   ` [nfsv4] " Nicolas Williams
2009-03-12 16:08   ` David P. Quigley
2009-03-12 17:20     ` Peter Staubach
2009-03-25  8:52 ` Jarrett Lu
2009-03-25 16:33   ` [nfsv4] " Nicolas Williams
2009-03-26  9:25     ` Jarrett Lu
2009-03-26 15:09       ` Nicolas Williams
2009-03-26 22:03         ` Jarrett Lu
2009-03-27  0:11           ` Nicolas Williams
2009-03-27 12:55             ` [Labeled-nfs] " Stephen Smalley
2009-03-27 13:22               ` Stephen Smalley
2009-03-27 17:03                 ` Jarrett Lu
2009-03-27 17:26                   ` [nfsv4] [Labeled-nfs] " Nicolas Williams
2009-03-27 18:56                     ` Jarrett Lu [this message]
2009-03-27 22:04                       ` Nicolas Williams
2009-03-30 17:37                       ` Stephen Smalley
2009-03-30 18:30                         ` Jarrett Lu
2009-03-30 20:01                           ` Nicolas Williams
2009-03-30 20:03                             ` Nicolas Williams
2009-03-30 21:14                           ` Stephen Smalley
2009-03-31  5:59                             ` Jarrett Lu
2009-03-31 18:28                               ` Nicolas Williams
2009-04-01  3:33                                 ` Jarrett Lu
2009-04-01  6:58                                   ` [Labeled-nfs] [nfsv4] " James Morris
2009-04-01  8:09                                     ` Jarrett Lu
2009-04-01  9:49                                       ` James Morris
2009-04-01 17:50                                   ` [nfsv4] [Labeled-nfs] " Nicolas Williams
2009-04-02 23:43                                     ` Jarrett Lu
2009-03-31  3:07                           ` Casey Schaufler
2009-03-31 14:47                             ` Paul Moore
2009-04-01  7:46                               ` Jarrett Lu
2009-04-01 16:46                                 ` Paul Moore
2009-04-02 15:24                                   ` Nicolas Williams
2009-04-02 22:35                                     ` Paul Moore
2009-04-03  4:42                                       ` Nicolas Williams
2009-04-03 18:08                                       ` Joy Latten
2009-04-03  1:21                                   ` Jarrett Lu
2009-04-07 21:30                                     ` Paul Moore
2009-03-31 18:34                             ` Nicolas Williams
2009-04-01  3:42                               ` Casey Schaufler
2009-03-28  3:33                   ` [Labeled-nfs] [nfsv4] " Casey Schaufler
2009-03-28  5:16                     ` Glenn Faden
2009-03-28  5:52                       ` Casey Schaufler
2009-03-27 22:09                 ` Nicolas Williams
2009-03-30 16:51                   ` Stephen Smalley
2009-03-30 20:05                     ` 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=49CD2169.3080209@sun.com \
    --to=jarrett.lu@sun.com \
    --cc=Nicolas.Williams@Sun.COM \
    --cc=labeled-nfs@linux-nfs.org \
    --cc=nfs-discuss@opensolaris.org \
    --cc=nfsv4@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.