New MAC label support Internet Draft posted to IETF website

New MAC label support Internet Draft posted to IETF website

[David P. Quigley]

Hello,
   I have just posted a new document for the MAC labeling support work
to the IETF website. It contains a lot of clarifying text that has been
asked for by several people in the IETF community. I would like to ask
that people give it a look over and provide comments if possible. I
would prefer that discussion takes place on the NFSv4 WG mailing list
since it shows interest in the technology which is what the WG is
currently looking for. If you have any questions regarding the text or
the system outlined in it email me and I'll be more than happy to help
with any confusion. I am hoping to drum up enough interest in the work
to request that it be added to the NFSv4 WG charter at the next IETF
meeting. If you are interested in the work and would like to participate
or just think that it is a worthwhile technology and would like to see
it added to the NFSv4 standard feel free to speak up. 

The information for the document which I received in the conformation
email and a link to it can be found below.

Dave Quigley


A new version of I-D, draft-quigley-nfsv4-sec-label-00.txt has been
successfuly submitted by David Quigley and posted to the IETF
repository.

Filename:        draft-quigley-nfsv4-sec-label
Revision:        00
Title:           MAC Security Label Support for NFSv4
Creation_date:   2009-01-22
WG ID:           Independent Submission
Number_of_pages: 12

Abstract:
This Internet-Draft describes additions to NFSv4 minor version one to
support Mandatory Access Control systems.  The current draft
describes the mechanism for transporting a MAC security label using
the NFSv4.1 protocol and the semantics required for that label.  In
addition to this it describes an example system of using this label
in a fully MAC aware environment.
                                                                                  


The IETF Secretariat.

http://www.ietf.org/internet-drafts/draft-quigley-nfsv4-sec-label-00.txt



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

Re: [nfsv4] New MAC label support Internet Draft posted to IETF website

[Peter Staubach]

Spencer Shepler wrote:
>
> As David suggests, the NFSv4 working group is positive about this
> work but until now, the show of specific interest within the NFSv4 
> working group
> has been very minimal.  If this work is to be added to the working 
> group's
> charter, there must be a show of interest.  This can be as simple as an
> email to the nfsv4@ietf.org alias stating interest and brief description
> of need/use.  This will demonstrate to the area director that work is
> occurring and it is worthwhile to have the NFSv4 WG undertake the
> work.
>
> So, please speak up, join the nfsv4 WG alias and participate as
> interest and need declares. 

I will start, I guess.

We, Red Hat, are looking at this work as enabling some fundamental
technologies for our virtual offerings.  We need the ability to
run SELinux over NFS mounted file systems and the current NFSv4[.1]
support is not sufficient to do it.

    Thanx...

       ps

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

RE: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Kevin L. Smith]

I can't speak as a representative of the project that I work on called Joint Cross Domain Exchange (JCDX), but we are porting our system from HP-UX 10.26 TOS to SELinx and need the capabilities of labeled NFS for our system.  David has been intrumental in helping me resolve issues and get us to the point where we can use this new capability.  

We only wish that labeled NFS could be mainstreamed sooner to get us out of the kernel building process.

Kevin Smith
Software Engineer
________________________________________
From: labeled-nfs-bounces@linux-nfs.org [labeled-nfs-bounces@linux-nfs.org] On Behalf Of Spencer Shepler [shepler@storspeed.com]
Sent: Friday, January 23, 2009 9:37 AM
To: David P. Quigley
Cc: labeled-nfs@linux-nfs.org; nfs-discuss@opensolaris.org; nfsv4@ietf.org; selinux@tycho.nsa.gov
Subject: Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

As David suggests, the NFSv4 working group is positive about this
work but until now, the show of specific interest within the NFSv4
working group
has been very minimal.  If this work is to be added to the working
group's
charter, there must be a show of interest.  This can be as simple as an
email to the nfsv4@ietf.org alias stating interest and brief description
of need/use.  This will demonstrate to the area director that work is
occurring and it is worthwhile to have the NFSv4 WG undertake the
work.

So, please speak up, join the nfsv4 WG alias and participate as
interest and need declares.

Spencer

On Jan 22, 2009, at 1:16 PM, David P. Quigley wrote:

> Hello,
>   I have just posted a new document for the MAC labeling support work
> to the IETF website. It contains a lot of clarifying text that has
> been
> asked for by several people in the IETF community. I would like to ask
> that people give it a look over and provide comments if possible. I
> would prefer that discussion takes place on the NFSv4 WG mailing list
> since it shows interest in the technology which is what the WG is
> currently looking for. If you have any questions regarding the text or
> the system outlined in it email me and I'll be more than happy to help
> with any confusion. I am hoping to drum up enough interest in the work
> to request that it be added to the NFSv4 WG charter at the next IETF
> meeting. If you are interested in the work and would like to
> participate
> or just think that it is a worthwhile technology and would like to see
> it added to the NFSv4 standard feel free to speak up.
>
> The information for the document which I received in the conformation
> email and a link to it can be found below.
>
> Dave Quigley
>
>
> A new version of I-D, draft-quigley-nfsv4-sec-label-00.txt has been
> successfuly submitted by David Quigley and posted to the IETF
> repository.
>
> Filename:        draft-quigley-nfsv4-sec-label
> Revision:        00
> Title:           MAC Security Label Support for NFSv4
> Creation_date:   2009-01-22
> WG ID:           Independent Submission
> Number_of_pages: 12
>
> Abstract:
> This Internet-Draft describes additions to NFSv4 minor version one to
> support Mandatory Access Control systems.  The current draft
> describes the mechanism for transporting a MAC security label using
> the NFSv4.1 protocol and the semantics required for that label.  In
> addition to this it describes an example system of using this label
> in a fully MAC aware environment.
>
>
>
> The IETF Secretariat.
>
> http://www.ietf.org/internet-drafts/draft-quigley-nfsv4-sec-label-00.txt
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
Labeled-nfs mailing list
Labeled-nfs@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/labeled-nfs


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

Re: [nfsv4] New MAC label support Internet Draft posted to IETF website

[Glenn Faden]

Sun is also positive about David's proposal although we currently don't 
depend on it.

Labeled NFS services are currently provided by Solaris Trusted 
Extensions, without relying on NFS protocol extensions. Instead, Trusted 
Extensions uses the labels of the network endpoints to determine the 
labels of the underlying clients and servers. When acting as an NFS 
server, Trusted Extensions sends packets at the same label as the 
underlying exported filesystem. These endpoint labels are then 
implicitly used to enforce mount policy restrictions by the NFS client 
and server code in the kernel. A restriction of this implementation is 
that all files in a NFS mounted filesystem must have the same label.

In order for Solaris to support per-file labeling we will need NFS 
protocol extensions similar to what David has proposed.

--Glenn

Peter Staubach wrote:
> Spencer Shepler wrote:
>>
>> As David suggests, the NFSv4 working group is positive about this
>> work but until now, the show of specific interest within the NFSv4 
>> working group
>> has been very minimal.  If this work is to be added to the working 
>> group's
>> charter, there must be a show of interest.  This can be as simple as an
>> email to the nfsv4@ietf.org alias stating interest and brief description
>> of need/use.  This will demonstrate to the area director that work is
>> occurring and it is worthwhile to have the NFSv4 WG undertake the
>> work.
>>
>> So, please speak up, join the nfsv4 WG alias and participate as
>> interest and need declares. 
>
> I will start, I guess.
>
> We, Red Hat, are looking at this work as enabling some fundamental
> technologies for our virtual offerings.  We need the ability to
> run SELinux over NFS mounted file systems and the current NFSv4[.1]
> support is not sufficient to do it.
>
>    Thanx...
>
>       ps
>
> -- 
> 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.


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

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

On 01/24/09 01:36, Lars Eggert wrote:
> Hi,
>
> On 2009-1-23, at 19:37, Spencer Shepler wrote:
>> If this work is to be added to the working group's
>> charter, there must be a show of interest.  This can be as simple as an
>> email to the nfsv4@ietf.org alias stating interest and brief description
>> of need/use.  This will demonstrate to the area director that work is
>> occurring and it is worthwhile to have the NFSv4 WG undertake the
>> work.
>
> community interest ("I'd use it if it existed") is necessary, but not 
> sufficient to charter new IETF work. We also need to determine if 
> there is a group of folks willing to commit to doing the work (writing 
> documents, reviewing documents, attending meetings, implement, etc.) 
> If you're willing to do this, please indicate it and let us know how 
> you'd contribute.

David's labeled-nfs extension is interesting to Sun Microsystems as both 
Solaris
Trusted Extensions and the Flexible Mandatory Access Control (FMAC) 
OpenSolaris
project will benefit from the proposed extension. I'm willing to 
dedicate time to
reviewing documents, attending meetings and discussions, and likely 
contributing
to implementation as well.

Jarrett

>
> Thanks,
> Lars
> ------------------------------------------------------------------------
>
> _______________________________________________
> Labeled-nfs mailing list
> Labeled-nfs@linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/labeled-nfs
>   


[-- Attachment #2: Type: text/html, Size: 2250 bytes --]

Re: New MAC label support Internet Draft posted to IETF website

[Peter Staubach]

David P. Quigley wrote:
> Hello,
>    I have just posted a new document for the MAC labeling support work
> to the IETF website. It contains a lot of clarifying text that has been
> asked for by several people in the IETF community. I would like to ask
> that people give it a look over and provide comments if possible. I
> would prefer that discussion takes place on the NFSv4 WG mailing list
> since it shows interest in the technology which is what the WG is
> currently looking for. If you have any questions regarding the text or
> the system outlined in it email me and I'll be more than happy to help
> with any confusion. I am hoping to drum up enough interest in the work
> to request that it be added to the NFSv4 WG charter at the next IETF
> meeting. If you are interested in the work and would like to participate
> or just think that it is a worthwhile technology and would like to see
> it added to the NFSv4 standard feel free to speak up. 
>
> The information for the document which I received in the conformation
> email and a link to it can be found below.
>
> Dave Quigley
>
>
> A new version of I-D, draft-quigley-nfsv4-sec-label-00.txt has been
> successfuly submitted by David Quigley and posted to the IETF
> repository.
>
> Filename:        draft-quigley-nfsv4-sec-label
> Revision:        00
> Title:           MAC Security Label Support for NFSv4
> Creation_date:   2009-01-22
> WG ID:           Independent Submission
> Number_of_pages: 12
>
> Abstract:
> This Internet-Draft describes additions to NFSv4 minor version one to
> support Mandatory Access Control systems.  The current draft
> describes the mechanism for transporting a MAC security label using
> the NFSv4.1 protocol and the semantics required for that label.  In
> addition to this it describes an example system of using this label
> in a fully MAC aware environment.
>                                                                                   
>
>
> The IETF Secretariat.
>
> http://www.ietf.org/internet-drafts/draft-quigley-nfsv4-sec-label-00.txt

I have been looking at the document and have some comments,
questions, and suggestions --

In section 1, MAC is defined, but perhaps it might be useful for
NFS folks to expand upon the definition just a tad.  For example,
how is this different than normal access control and why?  Perhaps
I am dense, but the text in Section 3 might make better sense if
I understood a little more about MAC at a high level.

In Section 3, there is discussion of using a recommended attribute
to store the security attribute.  A request is made for security
attribute number 76.  This one appears to be used already in the
NFSv4.1 specification.  Perhaps this should be flagged so that it
can be updated appropriate when this specification is included
into a larger, NFSv4.2, document?

In Section 3.1, DOI is defined for a third time.  The acronym can
probably just be used here.  That said, providing a little more
detail on how a DOI would be represented would be useful.  Is it
a 32 bit unsigned integer or something else?  Perhaps including
a pseudo description of the syntax of the security_attribute
would be good.

Section 3.2 discusses handling if a security attribute is
changed while a client is holding a delegation to an object.
The text describes that the client should flush changes to the
server and relinquish the delegation.  Why?  Is access to an
open file on the client to be revoked?  What happens on a
client which does not happen to be holding a delegation at the
time?

This leads to a further question concerning client side caching
of these attributes.  Is the client allowed to do caching?  If
so, how would it go about doing cache validation?

Section 4.1 includes an XXX reference probably to a draft
document.  Is this the draft for RPCSEC_GSSAPI v3?

Section 4.1.1 discusses denying a request if a security
attribute can not be translated from one DOI to another.
What error should be returned?  It seems to me that a new
set of errors may potentially need to be introduced to
handle the new cases where servers need to inform clients
exactly what happened.  Section 4.1.2 is missing a period
on the end of the second paragraph.  Perhaps this is the
intended error to be returned?

Section 4.2.1 discusses a smart client and the need for a
common DOI.  Could a client not implement its own translations
for the DOIs that it may choose to know about?

Section requests an IANA registry for DOIs.  Perhaps document
like, draft-ietf-nfsv4-rpc-netid-06.txt, previously circulated
by Michael Eisler, will need to be constructed to handle the
issue.

---

Anyway, enough for the time being.  I think that some more
detailed definitions and declarations need to be specified
in order to move along.

    Thanx...

       ps


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

Re: New MAC label support Internet Draft posted to IETF website

[David P. Quigley]

On Mon, 2009-02-09 at 17:24 -0500, Peter Staubach wrote:
> 
> I have been looking at the document and have some comments,
> questions, and suggestions --
> 
> In section 1, MAC is defined, but perhaps it might be useful for
> NFS folks to expand upon the definition just a tad.  For example,
> how is this different than normal access control and why?  Perhaps
> I am dense, but the text in Section 3 might make better sense if
> I understood a little more about MAC at a high level.

I will make an attempt to clarify this. I was trying to get a concise
definition into the draft without bogging it down with a whole bunch of
Access Control theory. However, if it isn't clear enough then I do need
to fix this.

> 
> In Section 3, there is discussion of using a recommended attribute
> to store the security attribute.  A request is made for security
> attribute number 76.  This one appears to be used already in the
> NFSv4.1 specification.  Perhaps this should be flagged so that it
> can be updated appropriate when this specification is included
> into a larger, NFSv4.2, document?

Hmm I picked that number from what I thought was an earlier v4.1
document. It's possible that I was looking at 4.0 proper instead. I
asked about grabbing a number a while back and someone said just take
one and we can fix it up later. A question for the WG is if there is a
proper procedure for this? Should I leave it blank with some sort of
marker like Peter suggests or is it as simple of just pick one for now
and we'll deal with conflicts if/when it gets chartered.

> 
> In Section 3.1, DOI is defined for a third time.  The acronym can
> probably just be used here.  That said, providing a little more
> detail on how a DOI would be represented would be useful.  Is it
> a 32 bit unsigned integer or something else?  Perhaps including
> a pseudo description of the syntax of the security_attribute
> would be good.

It seems reasonable at this point that the person will know what DOI
stands for and if not they can look it up in the terms section. There
are a few people doing transport layer work that have a definition of a
DOI. I originally had a marker in there that we should have a normative
reference to a draft about DOIs. The structure that most people seem to
be happy with is a 32 bit number that can be thought of as a series of 4
octets. This allows it to be easily partitioned into ranges for private
used among other things. The CALIPSO guys have a good starting point for
this and we talked about it at the DOI BOF last IETF. The consensus at
that meeting was that we should convene a full BOF to discuss it at a
future IETF. Between the Labeled IPSec drafts that are slowly making
their way to the IETF, the CALIPSO draft which is already far along, and
the Labeled NFS work we should probably have a standard definition for
DOIs including how they are registered, represented, what ranges are
reserved and for what purposed, etc. 

Even if this information is pulled in from a normative reference it
doesn't seem like a bad idea to explain part of it in this document. 

> 
> Section 3.2 discusses handling if a security attribute is
> changed while a client is holding a delegation to an object.
> The text describes that the client should flush changes to the
> server and relinquish the delegation.  Why?  Is access to an
> open file on the client to be revoked?  What happens on a
> client which does not happen to be holding a delegation at the
> time?

Well, this is standard behavior for delegation within NFSv4. If the
security label is changed from under a client you have an issue where it
could still be making local cached access decisions based on a label
that is now out of date. This may not be as stringent of a requirement
with DAC permissions but with MAC it's very important because the system
may be mediating read and write calls in addition to just open calls. If
the client doesn't have a delegation then it shouldn't have an open file
handle for the file. So when it opens the file it will get the valid
label.

Hmm, the text here seems a bit ambiguous. What I mean to say here is
that the label on the server changes while the client is holding the
delegation. There is a case to say that if it changes on the client that
if you really want to guarantee the file is protected on the server that
you shouldn't maintain local cached security attribute changes. However
it's not completely clear to me how the exported FS should react with
processes local to the server making access to files.

> 
> This leads to a further question concerning client side caching
> of these attributes.  Is the client allowed to do caching?  If
> so, how would it go about doing cache validation?

So as of right now we do standard attribute timeouts. In the Linux case
this is 5 seconds by default. I spoke with Nico briefly a while back
about this and he said what might be needed here was to provide some
sort of open file handle revocation support. In the past people have
suggested building the client's idea of the label into either the
stateid or some other form of cookie that can be verified by the server.
We explored doing this in the form of an NFSv4 op and while that worked
we are trying to shy away from adding new operations if we can help it.
I'm still open to potential solutions to this problem. 

> 
> Section 4.1 includes an XXX reference probably to a draft
> document.  Is this the draft for RPCSEC_GSSAPI v3?

That's exactly what it is referencing. I think the reason I left that
was because Nico hadn't posted it to the IETF website as a P-ID when I
had released this. It was made public but I don't think it was
submitted.

> 
> Section 4.1.1 discusses denying a request if a security
> attribute can not be translated from one DOI to another.
> What error should be returned?  It seems to me that a new
> set of errors may potentially need to be introduced to
> handle the new cases where servers need to inform clients
> exactly what happened.  Section 4.1.2 is missing a period
> on the end of the second paragraph.  Perhaps this is the
> intended error to be returned?

The error mentioned in 4.1.1 is the one referenced in 4.1.2
(NFS4ERR_ACCESS). I'll put it in section 4.1.1 as well if it makes
things clearer. I am open to adding a NFS4ERR_MACACCESS code or
something similar to that to provide additional information to
administrators as to why things are failing. I make mention in 4.3.2
that an administrator should be aware when he gets an access failure
using this functionality that it can possibly be caused by the MAC
policy. I probably need to find a better location for this tidbit of
information.

> 
> Section 4.2.1 discusses a smart client and the need for a
> common DOI.  Could a client not implement its own translations
> for the DOIs that it may choose to know about?

We made a decision that in an environment where the server just operates
as a dumb storage medium that it would bring huge problems to store the
DOI with the label. So in this kind of environment the security
attributes are stored without a DOI on the server so it isn't possible
to have those translations take place. The second half of that section
says why we made that decision. I should add to the security attribute
section that when an attribute shows up without the @DOI portion of the
string it should be treated as the null DOI. Either that or we should
atleast force these storage boxes to append @0 into the attribute. 

> 
> Section requests an IANA registry for DOIs.  Perhaps document
> like, draft-ietf-nfsv4-rpc-netid-06.txt, previously circulated
> by Michael Eisler, will need to be constructed to handle the
> issue.

I'll take a look into this document to see what we can learn from it.

> 
> ---
> 
> Anyway, enough for the time being.  I think that some more
> detailed definitions and declarations need to be specified
> in order to move along.

I noticed you didn't make any comments regarding section 5. This was the
most recent section added because some WG members expressed a desire to
see an extensive example of the system. Did you not comment because you
think its acceptable or are comments on that being put off till after I
address these. Also a question for the WG. Is that section effective in
providing understanding of the system? Is there something else that it
needs to contain? Are there ambiguities that I'm not seeing because I
have a background in the area?

Dave


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

Re: [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[James Morris]

On Wed, 11 Feb 2009, David P. Quigley wrote:

> sort of open file handle revocation support. In the past people have
> suggested building the client's idea of the label into either the
> stateid or some other form of cookie that can be verified by the server.
> We explored doing this in the form of an NFSv4 op and while that worked
> we are trying to shy away from adding new operations if we can help it.

What's wrong with adding new operations?


- James
-- 
James Morris
<jmorris@namei.org>

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

Re: [nfsv4] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Mon, Feb 09, 2009 at 05:24:32PM -0500, Peter Staubach wrote:
> Section 3.2 discusses handling if a security attribute is
> changed while a client is holding a delegation to an object.
> The text describes that the client should flush changes to the
> server and relinquish the delegation.  Why?  Is access to an
> open file on the client to be revoked?  What happens on a
> client which does not happen to be holding a delegation at the
> time?
> 
> This leads to a further question concerning client side caching
> of these attributes.  Is the client allowed to do caching?  If
> so, how would it go about doing cache validation?

For DAC POSIX semantics are that open file references are not revoked
when a file's owner/group/permissions (and/or ACL) change.

MAC requires some sort of revocation.  This can happen on the
server-side whenever the client tries to access a file after it's been
relabeled.  The client might learn of this pretty late, but given that
the user on the client would have been able to see the contents under
the old label this timing seems to me to be acceptable.

Recalling an open file delegation seems OK as a way to speed that up if
the client can obtain a new delegation if it still has access to the
file.

The only other wrinkle is that multi-user clients need to let the server
perform all access decisions for each user -- the client must not allow
access using local MAC decisions based on cached file labels.

> Section 4.1 includes an XXX reference probably to a draft
> document.  Is this the draft for RPCSEC_GSSAPI v3?

No, it's not.  As David explained, that I-D came later.

> Section 4.1.1 discusses denying a request if a security
> attribute can not be translated from one DOI to another.
> What error should be returned?  It seems to me that a new

IMO NFS4ERR_ACCESS is good enough.

> set of errors may potentially need to be introduced to
> handle the new cases where servers need to inform clients
> exactly what happened.  [...]

Perhaps, but I expect that production servers would return generic
errors like NFS4ERR_ACCESS rather than newfangled ones like, say,
NFS4ERR_NODOITRANS.  There's no need to tell the client too much about
why its request failed.  It suffices that access was denied, and for
that NFS4ERR_ACCESS is good enough.

> Section 4.2.1 discusses a smart client and the need for a
> common DOI.  Could a client not implement its own translations
> for the DOIs that it may choose to know about?

It could.

> Anyway, enough for the time being.  I think that some more
> detailed definitions and declarations need to be specified
> in order to move along.

Defnitely.

Thanks for the comments!

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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Thu, Feb 12, 2009 at 12:07:31PM +1100, James Morris wrote:
> On Wed, 11 Feb 2009, David P. Quigley wrote:
> 
> > sort of open file handle revocation support. In the past people have
> > suggested building the client's idea of the label into either the
> > stateid or some other form of cookie that can be verified by the server.
> > We explored doing this in the form of an NFSv4 op and while that worked
> > we are trying to shy away from adding new operations if we can help it.

The file handle should suffice.  The server can check if the label has
changed and then return an error.  If need be we could even use volatile
FHs for this (with the FH being somewhat like a capability).

> What's wrong with adding new operations?

In this case a new operation won't help since the server may want to
perform revocation as early as possible, and waiting for a client to use
a specific operation is not a good way to achieve that.  If you meant a
callback operation, sure, but the server needs to know what clients are
caching open file data and metadata, and right now the server only knows
about that when clients get delegations.  It might be possible to add a
callback operation to indicate that access must be re-evaluated but
without recalling a delegation.

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.

Re: [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[David P. Quigley]

On Thu, 2009-02-12 at 12:07 +1100, James Morris wrote:
> On Wed, 11 Feb 2009, David P. Quigley wrote:
> 
> > sort of open file handle revocation support. In the past people have
> > suggested building the client's idea of the label into either the
> > stateid or some other form of cookie that can be verified by the server.
> > We explored doing this in the form of an NFSv4 op and while that worked
> > we are trying to shy away from adding new operations if we can help it.
> 
> What's wrong with adding new operations?
> 
> 
> - James


For the sake of discussion I'll talk about the previous work we did on
this topic. In the presentation I gave at IETF 71 we had a new NFSv4
operation called OP_PUTCLIENTLABEL. The idea of this was it was to work
like a PUTFH call in that you would push some state to the server which
would be used to evaluate all portions of the compound operation after
it. The idea was that the client would say that it believes the file is
TOP SECRET by issuing a PUTCLIENTLABEL at the beginning of the compound
op with the label TOP SECRET as the value. When the server evaluated the
parts of the compound operation that used a file handle it would check
if the label for that FH matched the one asserted by the client in the
PUTCLIENTLABEL operation. If they didn't match, the server returned an
ESTALE error and hopefully the client would refetch the file handle. At
the time Linux didn't have good support for recovering from an ESTALE
but since then I believe that support was fixed.

Someone in the audience brought up that we possibly had the
PUTCLIENTLABEL op in the wrong place because it wasn't being protected
by one of the replay attack mechanisms. This would have been easy to fix
but some people seemed skeptical to doing this as a new operation (we
had a total of two or three that were being proposed). So we went back
and looked for another way to do it. James had suggested building it
into the stateid and Nico has suggested to use volatile FHs for it. 

When I gave a followup presentation at IETF 72 I mentioned that we had
removed the operations. After the presentation I believe Mike Eisler
mentioned that it was good that we avoided adding new operations. He
said that they were trying to make future revisions to NFSv4 (4.2 and
higher) move more quickly through the process since they would be
smaller revisions. We hoped making the required protocol changes smaller
would help move things along more quickly.

I'd like to hear more from Nico on how we can use volatile FHs to solve
this problem. The document still needs more work to take care of things
like this but I was hoping this revision could get the discussion
rolling so other people would provide input into the design. It seems
that it is getting attention now.

Dave


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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[David P. Quigley]

On Thu, 2009-02-12 at 09:36 -0600, Nicolas Williams wrote:
> On Thu, Feb 12, 2009 at 12:07:31PM +1100, James Morris wrote:
> > On Wed, 11 Feb 2009, David P. Quigley wrote:
> > 
> > > sort of open file handle revocation support. In the past people have
> > > suggested building the client's idea of the label into either the
> > > stateid or some other form of cookie that can be verified by the server.
> > > We explored doing this in the form of an NFSv4 op and while that worked
> > > we are trying to shy away from adding new operations if we can help it.
> 
> The file handle should suffice.  The server can check if the label has
> changed and then return an error.  If need be we could even use volatile
> FHs for this (with the FH being somewhat like a capability).
> 
> > What's wrong with adding new operations?
> 
> In this case a new operation won't help since the server may want to
> perform revocation as early as possible, and waiting for a client to use
> a specific operation is not a good way to achieve that.  If you meant a
> callback operation, sure, but the server needs to know what clients are
> caching open file data and metadata, and right now the server only knows
> about that when clients get delegations.  It might be possible to add a
> callback operation to indicate that access must be re-evaluated but
> without recalling a delegation.
> 
> Nico

We also explored a callback for label change notification. I think we
even have the code lying around for the prototype. It worked but Trond
expressed some concern with how well it would scale. The issue Trond
raised is what happens if you relabel an entire file system from under a
set of NFSv4 clients? I'm not sure how much of a concern this will be
since 1) File relabeling is supposed to be rare and 2) clients will
probably have a small subset of files open. In the event that you do
need to relabel the entire file system on the server it might be a good
idea from an administrative perspective to have your clients remount the
NFS shares and flush whatever caches they have.

Dave


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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Thu, Feb 12, 2009 at 03:00:51PM -0500, David P. Quigley wrote:
> We also explored a callback for label change notification. I think we
> even have the code lying around for the prototype. It worked but Trond
> expressed some concern with how well it would scale. The issue Trond
> raised is what happens if you relabel an entire file system from under a
> set of NFSv4 clients? I'm not sure how much of a concern this will be

Surely it would scale no better and no worse than open file delegation...

> since 1) File relabeling is supposed to be rare and 2) clients will
> probably have a small subset of files open. In the event that you do

Reclassification of data is supposed to be rare, though that may vary a
lot by environment.  The number of files that may be kept open provides
a natural limit to how many relabel callbacks will be needed.  (A client
could OPEN every file at limit cost to itself hoping to overwhelm a
server, but that's a separate issue.)

> need to relabel the entire file system on the server it might be a good
> idea from an administrative perspective to have your clients remount the
> NFS shares and flush whatever caches they have.

Well, there's no callback to tell clients to flush all writes and
remount (or recover).  You could simulate a server reboot and force
recovery though.

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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[David P. Quigley]

On Thu, 2009-02-12 at 14:11 -0600, Nicolas Williams wrote:
> On Thu, Feb 12, 2009 at 03:00:51PM -0500, David P. Quigley wrote:
> > We also explored a callback for label change notification. I think we
> > even have the code lying around for the prototype. It worked but Trond
> > expressed some concern with how well it would scale. The issue Trond
> > raised is what happens if you relabel an entire file system from under a
> > set of NFSv4 clients? I'm not sure how much of a concern this will be
> 
> Surely it would scale no better and no worse than open file delegation...
> 
> > since 1) File relabeling is supposed to be rare and 2) clients will
> > probably have a small subset of files open. In the event that you do
> 
> Reclassification of data is supposed to be rare, though that may vary a
> lot by environment.  The number of files that may be kept open provides
> a natural limit to how many relabel callbacks will be needed.  (A client
> could OPEN every file at limit cost to itself hoping to overwhelm a
> server, but that's a separate issue.)
> 
> > need to relabel the entire file system on the server it might be a good
> > idea from an administrative perspective to have your clients remount the
> > NFS shares and flush whatever caches they have.
> 
> Well, there's no callback to tell clients to flush all writes and
> remount (or recover).  You could simulate a server reboot and force
> recovery though.
> 
> Nico

So can anyone see of another use for providing a call back that would
tell a client to flush it's cached changes back to the server and start
a recovery? It could be a potential solution to large scale relabeling
on the server but I hesitate to propose it unless it has more than just
that application. Also aren't callbacks done out of band and if a
callback channel can't be established the functionality is just dropped?

Dave


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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Tue, Feb 17, 2009 at 11:50:50AM -0500, David P. Quigley wrote:
> So can anyone see of another use for providing a call back that would
> tell a client to flush it's cached changes back to the server and start
> a recovery? It could be a potential solution to large scale relabeling
> on the server but I hesitate to propose it unless it has more than just
> that application. Also aren't callbacks done out of band and if a
> callback channel can't be established the functionality is just dropped?

I don't think that timely revocation, extending to cached data on
clients, is a problem that we need to address for labeling.  It's a
problem in general and one that most users and implementors probably
don't care that much about.  Timely revocation can always be addressed
separately if it becomes sufficiently desirable.  IMO: leave it out of
scope.

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.

Re: New MAC label support Internet Draft posted to IETF website

[David P. Quigley]

So I am addressing the comments from the mailing list in the Labeled
NFSv4 draft and currently I'm working on Peter's concerns about the
delegation section. Reading through the NFSv4.1-29 version of the
specification it seems that section 10.2 gives all the reasons why this
should be done. Would it be wise to repeat some of the reasons in the
Labeled NFSv4 document or is it fine for me to reference section 10.2 of
the NFSv4.1 spec? 

Dave


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

Re: New MAC label support Internet Draft posted to IETF website

[Peter Staubach]

David P. Quigley wrote:
> So I am addressing the comments from the mailing list in the Labeled
> NFSv4 draft and currently I'm working on Peter's concerns about the
> delegation section. Reading through the NFSv4.1-29 version of the
> specification it seems that section 10.2 gives all the reasons why this
> should be done. Would it be wise to repeat some of the reasons in the
> Labeled NFSv4 document or is it fine for me to reference section 10.2 of
> the NFSv4.1 spec?

My expectation would be that the goal would be to be part of the
NFSv4.2 specification, so I would think that referencing the section
of the NFSv4.1 specification would help the document editor.

       ps

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

Re: New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

David P. Quigley wrote:
> Hello,
>    I have just posted a new document for the MAC labeling support work
> to the IETF website. It contains a lot of clarifying text that has been
> asked for by several people in the IETF community. I would like to ask
> that people give it a look over and provide comments if possible. I
> would prefer that discussion takes place on the NFSv4 WG mailing list
> since it shows interest in the technology which is what the WG is
> currently looking for. If you have any questions regarding the text or
> the system outlined in it email me and I'll be more than happy to help
> with any confusion. I am hoping to drum up enough interest in the work
> to request that it be added to the NFSv4 WG charter at the next IETF
> meeting. If you are interested in the work and would like to participate
> or just think that it is a worthwhile technology and would like to see
> it added to the NFSv4 standard feel free to speak up. 
>
> The information for the document which I received in the conformation
> email and a link to it can be found below.
>
> Dave Quigley
>
>
>
> http://www.ietf.org/internet-drafts/draft-quigley-nfsv4-sec-label-00.txt
>   

Sorry about the late reply. I have the following comments on the draft.

1. section 3, a nit. It's probably better to number your requirements as 
R1, R2, ... R4. When you refer to them later in your draft, I don't need 
to count every time.

2. section 3, the semantics of DOI in your draft is different from the 
one in the CALIPSO draft. Traditionally, DOI in MLS context refers to 
(at least in part) administrative control and deployment of the MLS 
systems. For example, DOD may own a block of DOIs. Systems using that 
block of DOIs are permitted to communicate with on another. Label 
translations are possible among the DOIs. Systems are not permitted to 
accept data packets carrying DOI outside a known DOI range. In your 
draft, DOI is used to imply label format in the opaque field of the 
security attribute. This makes it impossible to share the CALIPSO DOI.

3. section 3, on a MAC system, every subject and object has a label as 
you stated. Different objects are labeled in different layers or 
subsystems. For example, data packets, network interface, sockets are 
labeled by IP module. I believe the draft should at least state that 
NFSv4 MAC labeling should be consistent with MAC policy on the entire 
system. Take MLS system as an example, it's considered a MAC violation 
that a file labeled SECRET goes out on a network interface labeled 
UNCLASSIFIED. It's important that NFS implements this correctly so that 
MAC is enforced correctly on the system. It's difficult for IP module to 
inspect whether NFS has put the correct label in IP's payload.

4. section 4, the draft should probably state how a MAC client knows 
whether the server is MAC aware or not, via configuration? Also how a 
MAC aware server knows whether the client is MAC aware, via 
configuration or based on the fact that security attributes are present?

5. section 4, nit. "MAC aware client/server" are probably better names 
than "smart client/server".

6. section 4.1, in full mode, does reply carry a label? It appears to me 
that a client never needs to do a DOI translation. The draft should be 
more explicit on  that, IMO.

7. section 4.2.2, the phrase "this may fail based on the DAC criteria 
even if the MAC policy grants access" applies to all three modes of 
operation. It may mislead reader to believe it only applies to this mode.

8. section 4.3, what actually prevents a MAC aware server to serve a 
mixture of MAC aware and MAC unaware clients? This restriction may not 
be necessary. There are environments where both kinds of clients coexist.

9. section 5.1, while I understand what you intend to explain, your 
example is not completely correct. In B&L MLS model, a request with TOP 
SECRET security attributes can actually read SECRET or UNCLASSIFIED 
directory. It's not a MAC violation, i.e. read down is OK. The reverse 
is not permitted.

10. section 7, as stated above, you seem to use the DOI field 
differently. It appears that you want the DOI to indicate whether an 
NSFv4 server understands the label format AND knows how to interpret the 
opaque field. This implies the server has to know all the label 
definitions for all valid DOIs. For example, a server must be able to 
detect a label is undefined under a DOI although it knows the format of 
the label. This may be better solved via configuration instead of going 
through IANA. For example, if one wants his server to be able to 
translate among three labeling schemes, she/he will configure the system 
with all three label definitions, translation tables, modules containing 
appropriate label functions and utilities, etc..


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.

Re: [nfsv4] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Wed, Mar 25, 2009 at 01:52:49AM -0700, Jarrett Lu wrote:
> 2. section 3, the semantics of DOI in your draft is different from the 
> one in the CALIPSO draft. Traditionally, DOI in MLS context refers to 
> (at least in part) administrative control and deployment of the MLS 
> systems. For example, DOD may own a block of DOIs. Systems using that 
> block of DOIs are permitted to communicate with on another. Label 
> translations are possible among the DOIs. Systems are not permitted to 
> accept data packets carrying DOI outside a known DOI range. In your 
> draft, DOI is used to imply label format in the opaque field of the 
> security attribute. This makes it impossible to share the CALIPSO DOI.

Before CALIPSO it's always been the case that the form of a label
depends on the DOI it is from, with a DOI being either implied by
context or explicit on the wire.

A CALIPSO DOI is, AFAICT, a DOI that imposes an MLS form on the label
(though with label encoding being protocol specific) and a security
policy registration/definition requirement.  CALIPSO also requires that
a DOI always be explicit.  CALIPSO also imposes a namespace of DOIs, and
I'm not sure that it allows any DOIs that are not CALIPSO DOIs.  CALIPSO 

In other words, any protocol that carries a {DOI ID, opaque label}
should be compatible with CALIPSO.

But an implementation that adheres to CALIPSO will not be able to use
non-CALIPSO DOIs.  Is that correct?  If so we need to ensure that a
mapping between MLS and DTE is possible, since David, IIRC, wants
support for DTE.  But as far as I can tell such a mapping is possible.

One thing I think is wrong with section 3.1 is that it talks about
translation of a label "into a form that is usable by the endpoint."
That's superfluous -- it should suffice to say that the DOI field allows
the server to know how to interpret the label if it understands the
given DOI.

> 3. section 3, on a MAC system, every subject and object has a label as 
> you stated. Different objects are labeled in different layers or 
> subsystems. For example, data packets, network interface, sockets are 
> labeled by IP module. I believe the draft should at least state that 
> NFSv4 MAC labeling should be consistent with MAC policy on the entire 
> system. Take MLS system as an example, it's considered a MAC violation 
> that a file labeled SECRET goes out on a network interface labeled 
> UNCLASSIFIED. It's important that NFS implements this correctly so that 
> MAC is enforced correctly on the system. It's difficult for IP module to 
> inspect whether NFS has put the correct label in IP's payload.

Agreed.

> 4. section 4, the draft should probably state how a MAC client knows 
> whether the server is MAC aware or not, via configuration? Also how a 
> MAC aware server knows whether the client is MAC aware, via 
> configuration or based on the fact that security attributes are present?

A client has to know a priori somehow whether to trust a server for a
specific range of labels in some DOI.  The MAC awareness or non-
awareness of a server relates only to how the label of an object is to
be determined (MAC server: the server tells you the object's label;
non-MAC server: the object's location determines the object's label) and
how authorization is to be done (MAC server: the server does MAC and DAC
authorization; non-MAC server: the server does DAC and the clients to
MAC authorization, with the clients having to all have a consistent
configuration).

> 5. section 4, nit. "MAC aware client/server" are probably better names 
> than "smart client/server".

Agreed.

> 6. section 4.1, in full mode, does reply carry a label? It appears to me 
> that a client never needs to do a DOI translation. The draft should be 
> more explicit on  that, IMO.

A client may have to do a DOI translation for reasons unknown to us, but
we should probably not even mention that.   Is that what you mean?

> 8. section 4.3, what actually prevents a MAC aware server to serve a 
> mixture of MAC aware and MAC unaware clients? This restriction may not 
> be necessary. There are environments where both kinds of clients coexist.

I agree.  A MAC aware server can certainly speak to MAC-unaware clients
by coercing all processes (open owners) on the client to a single label
determined via server-side configuration.

> 10. section 7, as stated above, you seem to use the DOI field 
> differently. It appears that you want the DOI to indicate whether an 
> NSFv4 server understands the label format AND knows how to interpret the 
> opaque field. This implies the server has to know all the label 
> definitions for all valid DOIs.

Well, for all the DOIs it knows about, for what else is a "valid DOI"?

>                                 For example, a server must be able to 
> detect a label is undefined under a DOI although it knows the format of 
> the label.

But if the server understands a given DOI then can do that.

>            This may be better solved via configuration instead of going 
> through IANA. For example, if one wants his server to be able to 
> translate among three labeling schemes, she/he will configure the system 
> with all three label definitions, translation tables, modules containing 
> appropriate label functions and utilities, etc..

It should be possible for a server to support multiple DOIs without
necessarily having to know how to translate between them.  Then you get:
processes with labels in one DOI cannot access objects with labels in
another.

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.

Re: [nfsv4] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

Nicolas Williams wrote:
> On Wed, Mar 25, 2009 at 01:52:49AM -0700, Jarrett Lu wrote:
>   
>> 2. section 3, the semantics of DOI in your draft is different from the 
>> one in the CALIPSO draft. Traditionally, DOI in MLS context refers to 
>> (at least in part) administrative control and deployment of the MLS 
>> systems. For example, DOD may own a block of DOIs. Systems using that 
>> block of DOIs are permitted to communicate with on another. Label 
>> translations are possible among the DOIs. Systems are not permitted to 
>> accept data packets carrying DOI outside a known DOI range. In your 
>> draft, DOI is used to imply label format in the opaque field of the 
>> security attribute. This makes it impossible to share the CALIPSO DOI.
>>     
>
> Before CALIPSO it's always been the case that the form of a label
> depends on the DOI it is from, with a DOI being either implied by
> context or explicit on the wire.
>   

CALIPSO DOI is intended for IP packets. Nodes using same DOI value 
implies that they all agree on how to interpret a MAC label. In that 
sense, it's more about label definition and encodings, less about its 
format. For example, host A and host B use a label encoding where label 
CONFIDENTIAL dominates label INTERNAL. A and B communicate using DOI 1. 
Host C and D both use a compatible label encoding. But in their label 
definition, label INTERNAL dominates label CONFIDENTIAL. C and D can 
communicate using DOI 2 without any problems. But host A is not allowed 
to communicate with host C using DOI 1, despite their label format may 
be compatible. I believe CALIPSO DOI assumes that host A and B are under 
the same administrative control. The administrative authority is 
supposed to register the DOI number with IANA for its use.

CALIPSO spec is very clear that the first thing IP checks is DOI number. 
IP drops packets if the DOI is unexpected. CALIPSO hasn't changed how 
DOI is used in that regard. Sun's trusted OS has similar behavior for a 
long time. That's DOI for IP module. It appear that labeled NFSv4 wants 
a different DOI, or different semantics of DOI. Using the example above, 
it seems to desire the following semantics:

DOI value      Opaque Security Attribute Field
---------      -------------------------------
    1          CALIPSO MLS label using label encodings shared by A, B
    2          CALIPSO MLS label using label encodings shared by C, D
    3          Redhat DTE label using security policy shared by A, B
    4          OpenSolaris FMAC DTE label using sec policy shared by C, D
    5          BSD's Biba label using security policy shared by C, D
   ....
 
In an MLS example, server host C gets a request from client host A with 
DOI = 1, requester label = CONFIDENTIAL. The client wants to write to 
file foo, which is protected by label INTERNAL under DOI 2. Server C 
validates that CONFIDENTIAL is a defined label in label encodings under 
DOI 1. It then translates the label and concludes that CONFIDENTIAL in 
DOI 1 is equivalent to INTERNAL in DOI 2, it then grants the write 
access to object foo (note in MLS, write access requires labels being 
equal).

I am having difficulty with how to manage DOIs with different 
combinations in the opaque field.

> A CALIPSO DOI is, AFAICT, a DOI that imposes an MLS form on the label
> (though with label encoding being protocol specific) and a security
> policy registration/definition requirement.  CALIPSO also requires that
> a DOI always be explicit.  CALIPSO also imposes a namespace of DOIs, and
> I'm not sure that it allows any DOIs that are not CALIPSO DOIs.  CALIPSO 
>
> In other words, any protocol that carries a {DOI ID, opaque label}
> should be compatible with CALIPSO.
>   

Whenever a packet carries a CALIPSO label, explicit DOI is mandatory.
The DOI is for validation purpose, it doesn't say anything about how the 
node should interpret the label. The "how to" part is already agreed 
upon by the virtue of using the same DOI.

> But an implementation that adheres to CALIPSO will not be able to use
> non-CALIPSO DOIs.  Is that correct?  If so we need to ensure that a
> mapping between MLS and DTE is possible, since David, IIRC, wants
> support for DTE.  But as far as I can tell such a mapping is possible.
>   

If labeled NFSv4 DOI is used to indicate how the opaque field should be 
interpreted, it needs its own DOI, as CALIPSO DOI isn't intended for 
that use. I don't believe this DOI should be in IANA registry. A system 
may support translation of a few MAC labels. Those systems should be 
configured to do so.

> One thing I think is wrong with section 3.1 is that it talks about
> translation of a label "into a form that is usable by the endpoint."
> That's superfluous -- it should suffice to say that the DOI field allows
> the server to know how to interpret the label if it understands the
> given DOI.
>   
>   
>> 4. section 4, the draft should probably state how a MAC client knows 
>> whether the server is MAC aware or not, via configuration? Also how a 
>> MAC aware server knows whether the client is MAC aware, via 
>> configuration or based on the fact that security attributes are present?
>>     
>
> A client has to know a priori somehow whether to trust a server for a
> specific range of labels in some DOI.  The MAC awareness or non-
> awareness of a server relates only to how the label of an object is to
> be determined (MAC server: the server tells you the object's label;
> non-MAC server: the object's location determines the object's label) and
> how authorization is to be done (MAC server: the server does MAC and DAC
> authorization; non-MAC server: the server does DAC and the clients to
> MAC authorization, with the clients having to all have a consistent
> configuration).
>   

I spoke to David about this. He is of the opinion that a MAC aware 
client should not care whether the server is MAC aware. I guess that 
means client always provides label attributes to server, and MAC unaware 
server just ignores it. But I agree with you that MAC aware clients 
should somehow know whether the server is MAC aware so that the client 
is clear on whose responsibility it is to set label of an object. It's 
also more robust to be able to detect the error case where a MAC aware 
server should set label attributes but fails to do so.

>> 6. section 4.1, in full mode, does reply carry a label? It appears to me 
>> that a client never needs to do a DOI translation. The draft should be 
>> more explicit on  that, IMO.
>>     
>
> A client may have to do a DOI translation for reasons unknown to us, but
> we should probably not even mention that.   Is that what you mean?
>   

If a client also needs to do DOI translation, the document should 
explicit about  that and say that replies from server should also carry 
DOI. That way, implementors know what kind of client they need to build 
to be compliant. Requiring client to do translation adds quite a bit of 
complexity. It's probably better not requiring that, until we know for 
sure that is needed.

>   
>> 10. section 7, as stated above, you seem to use the DOI field 
>> differently. It appears that you want the DOI to indicate whether an 
>> NSFv4 server understands the label format AND knows how to interpret the 
>> opaque field. This implies the server has to know all the label 
>> definitions for all valid DOIs.
>>     
>
> Well, for all the DOIs it knows about, for what else is a "valid DOI"?
>   

I still haven't figured out how to use the DOI and the opaque field to 
make different MAC systems to interoperate. We still have some work to 
do to standardize that. If any combination of label format, policy, 
encondings, definition, etc. requires a different DOI, it becomes 
unmanageable quickly.

>   
>>                                 For example, a server must be able to 
>> detect a label is undefined under a DOI although it knows the format of 
>> the label.
>>     
>
> But if the server understands a given DOI then can do that.
>
>   
>>            This may be better solved via configuration instead of going 
>> through IANA. For example, if one wants his server to be able to 
>> translate among three labeling schemes, she/he will configure the system 
>> with all three label definitions, translation tables, modules containing 
>> appropriate label functions and utilities, etc..
>>     
>
> It should be possible for a server to support multiple DOIs without
> necessarily having to know how to translate between them.  Then you get:
> processes with labels in one DOI cannot access objects with labels in
> another.
>   

Yes, that's possible, and this is simpler than having to translate. I 
don't know enough use cases to know whether users keep multiple file 
systems on same server but protect them with two sets of labels.

Thanks.

Jarrett

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

Re: [nfsv4] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

Jarret,

I agree with your point about interoperability: we must impose a label
encoding.  We can leave parts of the DOI number space reserved for
as-yet-unspecified label forms and encodings -- that would satisfy my
desire for extensibility.  That's a comment I should make on CALIPSO,
that it should not impose its label structure and encoding on all DOIs,
just all DOIs in parts of the DOI number space open for registration.

Also, this does not mean that the label shouldn't be opaque in the XDR
sense.  Using opaque in the XDR sense but actually imposing a label
encoding might still be desirable (mostly for compression, but also if
we should reserve some of the DOI number space for as-yet-unspecified
label structures and encodings).

On Thu, Mar 26, 2009 at 02:25:44AM -0700, Jarrett Lu wrote:
> Nicolas Williams wrote:
> >On Wed, Mar 25, 2009 at 01:52:49AM -0700, Jarrett Lu wrote:
> >>2. section 3, the semantics of DOI in your draft is different from the 
> >>one in the CALIPSO draft. Traditionally, DOI in MLS context refers to 
> >>[...]
> >
> >Before CALIPSO it's always been the case that the form of a label
> >depends on the DOI it is from, with a DOI being either implied by
> >context or explicit on the wire.
> >  
> 
> CALIPSO DOI is intended for IP packets. Nodes using same DOI value 

Yes, and there's a relationship to the application data.  Thus, for
example, the label used for packets carrying NFS traffic has to dominate
the labels of the files being accessed via NFS.

That means that CALIPSO has an impact beyond IP.  Specifically,
CALIPSO's imposition of structure on labels of any DOIs with DOI ID <
2^32 applies to applications as well.

> implies that they all agree on how to interpret a MAC label. In that 
> sense, it's more about label definition and encodings, less about its 
> format. For example, host A and host B use a label encoding where label 
> CONFIDENTIAL dominates label INTERNAL. A and B communicate using DOI 1. 

CALIPSO imposes structure on labels, not encoding (it does define an
encoding for use in IPsec though).  The structure is: DOI, sensitivity
level, compartments, releasability.  We'll need to pick an encoding.

> CALIPSO spec is very clear that the first thing IP checks is DOI number. 
> IP drops packets if the DOI is unexpected. CALIPSO hasn't changed how 
> DOI is used in that regard. Sun's trusted OS has similar behavior for a 
> long time. That's DOI for IP module. It appear that labeled NFSv4 wants 
> a different DOI, or different semantics of DOI. Using the example above, 
> it seems to desire the following semantics:

David seems to want explicit support for DTE.  If we can get away with a
combination of MLS (and, maybe, privileges) to represent DTE then we can
stick exclusively to MLS and remain compliant with CALIPSO.  Given the
impact that CALIPSO has on application protocols I think we have no
choice (see above).

> DOI value      Opaque Security Attribute Field
> ---------      -------------------------------
>    1          CALIPSO MLS label using label encodings shared by A, B
>    2          CALIPSO MLS label using label encodings shared by C, D
>    3          Redhat DTE label using security policy shared by A, B
>    4          OpenSolaris FMAC DTE label using sec policy shared by C, D
>    5          BSD's Biba label using security policy shared by C, D
>   ....
> 
> In an MLS example, server host C gets a request from client host A with 
> DOI = 1, requester label = CONFIDENTIAL. The client wants to write to 
> file foo, which is protected by label INTERNAL under DOI 2. Server C 
> validates that CONFIDENTIAL is a defined label in label encodings under 
> DOI 1. It then translates the label and concludes that CONFIDENTIAL in 
> DOI 1 is equivalent to INTERNAL in DOI 2, it then grants the write 
> access to object foo (note in MLS, write access requires labels being 
> equal).

I think that's the sort of thing that David was aiming for, yes.

> I am having difficulty with how to manage DOIs with different 
> combinations in the opaque field.

I agree that it's best to have an encoding for the label than to leave
it opaque.  I want a range of unknown DOIs with opque labels for
extensibility though (see above).

> >A CALIPSO DOI is, AFAICT, a DOI that imposes an MLS form on the label
> >(though with label encoding being protocol specific) and a security
> >policy registration/definition requirement.  CALIPSO also requires that
> >a DOI always be explicit.  CALIPSO also imposes a namespace of DOIs, and
> >I'm not sure that it allows any DOIs that are not CALIPSO DOIs.  CALIPSO 
> >
> >In other words, any protocol that carries a {DOI ID, opaque label}
> >should be compatible with CALIPSO.

I should have qualified that last statement: "any protocol that carries
a {DOI ID, opaque label} _and can use MLS exclusively_ should be
compatible with CALIPSO."

> Whenever a packet carries a CALIPSO label, explicit DOI is mandatory.

David's I-D has that.

> >But an implementation that adheres to CALIPSO will not be able to use
> >non-CALIPSO DOIs.  Is that correct?  If so we need to ensure that a
> >mapping between MLS and DTE is possible, since David, IIRC, wants
> >support for DTE.  But as far as I can tell such a mapping is possible.
> 
> If labeled NFSv4 DOI is used to indicate how the opaque field should be 

In David's I-D the encoding of the label is left to each DOI.  That's
not unreasonable.  But in the face of CALIPSO we might as well specify
an actual label encoding given that CALIPSO imposes label structure.

> >>[...]
> >
> >A client has to know a priori somehow whether to trust a server for a
> >specific range of labels in some DOI.  The MAC awareness or non-
> >awareness of a server relates only to how the label of an object is to
> >be determined (MAC server: the server tells you the object's label;
> >non-MAC server: the object's location determines the object's label) and
> >how authorization is to be done (MAC server: the server does MAC and DAC
> >authorization; non-MAC server: the server does DAC and the clients to
> >MAC authorization, with the clients having to all have a consistent
> >configuration).
> >  
> 
> I spoke to David about this. He is of the opinion that a MAC aware 
> client should not care whether the server is MAC aware. I guess that 
> means client always provides label attributes to server, and MAC unaware 
> server just ignores it. But I agree with you that MAC aware clients 
> should somehow know whether the server is MAC aware so that the client 
> is clear on whose responsibility it is to set label of an object. It's 
> also more robust to be able to detect the error case where a MAC aware 
> server should set label attributes but fails to do so.

I agree with you and disagree with David then on this:

 - MAC-unaware clients must be treated as being at a single label.

 - MAC-unaware servers must either be treated as being at a single label
   or filesystem object labels must be derived from the fsid of each
   object.

   The latter is more or less the Solaris TX approach to file labeling
   in general right now, and it requires that all MAC-aware clients be
   configured the same way.  It also effectively requires that all
   clients of MAC-unaware servers be MAC-aware, which is why MAC-unaware
   servers will be difficult to use in practice.

> If a client also needs to do DOI translation, the document should 
> explicit about  that and say that replies from server should also carry 
> DOI. That way, implementors know what kind of client they need to build 
> to be compliant. Requiring client to do translation adds quite a bit of 
> complexity. It's probably better not requiring that, until we know for 
> sure that is needed.

The DOI should always be explicit in NFSv4.x, yes.  I think that DOI
translation will never really happen, thus we should probably chuck it.

> >It should be possible for a server to support multiple DOIs without
> >necessarily having to know how to translate between them.  Then you get:
> >processes with labels in one DOI cannot access objects with labels in
> >another.
> 
> Yes, that's possible, and this is simpler than having to translate. I 
> don't know enough use cases to know whether users keep multiple file 
> systems on same server but protect them with two sets of labels.

I'm thinking of a single storage infrastructure serving clients from
multiple DOIs, with each DOI kept strictly separated by server policy,
thus no two DOIs "meet."  Granted, such a thing can be implemented via
virtualization.

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.

Re: [nfsv4] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

Nicolas Williams wrote:
> Jarret,
>
> I agree with your point about interoperability: we must impose a label
> encoding.  We can leave parts of the DOI number space reserved for
> as-yet-unspecified label forms and encodings -- that would satisfy my
> desire for extensibility.  That's a comment I should make on CALIPSO,
> that it should not impose its label structure and encoding on all DOIs,
> just all DOIs in parts of the DOI number space open for registration.
>   

CALIPSO spec doesn't tie a DOI with a particular label encoding. For 
example, it DOI 1000 doesn't have to mean it's CALIPSO label with this 
label encoding file. DOI 1000 could very well be used by SELinux systems 
using a particular MAC policy. CALIPSO DOI does imply that when a node 
can communicate with a DOI, it knows how to interpret the labels 
associated with the DOI. All nodes using the same DOI have agreed on 
what format and encodings to use. The agreement takes place else where, 
most likely an administrative decision. Does labeled NFSv4 aim to 
establish this agreement within the protocol itself?
> Also, this does not mean that the label shouldn't be opaque in the XDR
> sense.  Using opaque in the XDR sense but actually imposing a label
> encoding might still be desirable (mostly for compression, but also if
> we should reserve some of the DOI number space for as-yet-unspecified
> label structures and encodings).
>   


CALIPSO spec reserves DOI value 1 - 255 for private use. If an 
organization doesn't want to do labeled communication outside its 
control, it can use a number in that range, without need to register 
with IANA.

> On Thu, Mar 26, 2009 at 02:25:44AM -0700, Jarrett Lu wrote:
>   
>> Nicolas Williams wrote:
>>     
>>> On Wed, Mar 25, 2009 at 01:52:49AM -0700, Jarrett Lu wrote:
>>>       
>>>> 2. section 3, the semantics of DOI in your draft is different from the 
>>>> one in the CALIPSO draft. Traditionally, DOI in MLS context refers to 
>>>> [...]
>>>>         
>>> Before CALIPSO it's always been the case that the form of a label
>>> depends on the DOI it is from, with a DOI being either implied by
>>> context or explicit on the wire.
>>>  
>>>       
>> CALIPSO DOI is intended for IP packets. Nodes using same DOI value 
>>     
>
> Yes, and there's a relationship to the application data.  Thus, for
> example, the label used for packets carrying NFS traffic has to dominate
> the labels of the files being accessed via NFS.
>   

Typically, SECRET data/file traffic doesn't leave SECRET network. So 
labels in different layers/subsystems should match. What must not happen 
is SECRET data flowing through UNCLASSIFIED network. In other words, we 
don't want to see a request coming in from UNCLASIFFIED  interface 
asking for SECRET files.

> That means that CALIPSO has an impact beyond IP.  Specifically,
> CALIPSO's imposition of structure on labels of any DOIs with DOI ID <
> 2^32 applies to applications as well.
>
>   
>> implies that they all agree on how to interpret a MAC label. In that 
>> sense, it's more about label definition and encodings, less about its 
>> format. For example, host A and host B use a label encoding where label 
>> CONFIDENTIAL dominates label INTERNAL. A and B communicate using DOI 1. 
>>     
>
> CALIPSO imposes structure on labels, not encoding (it does define an
> encoding for use in IPsec though).  The structure is: DOI, sensitivity
> level, compartments, releasability.  We'll need to pick an encoding.
>   

By label encoding, I mean how a CALIPSO label represented in a more 
basic form (e.g. hex or binary). It's usually done in a file, e.g. 
0x000300a0000 translates to SECRET and it dominates 0x0001007000. 
Security administrators control the encoding. They get to say what 
labels are valid and how valid label relate to each other on their 
systems. Given this kind of local control, I don't know how we, who 
defined protocol attributes, could pick one. The way it works is that 
they (administrators) picked one, and agreed among themselves what label 
encoding and DOI to use.

>   
>> CALIPSO spec is very clear that the first thing IP checks is DOI number. 
>> IP drops packets if the DOI is unexpected. CALIPSO hasn't changed how 
>> DOI is used in that regard. Sun's trusted OS has similar behavior for a 
>> long time. That's DOI for IP module. It appear that labeled NFSv4 wants 
>> a different DOI, or different semantics of DOI. Using the example above, 
>> it seems to desire the following semantics:
>>     
>
> David seems to want explicit support for DTE.  If we can get away with a
> combination of MLS (and, maybe, privileges) to represent DTE then we can
> stick exclusively to MLS and remain compliant with CALIPSO.  Given the
> impact that CALIPSO has on application protocols I think we have no
> choice (see above).
>   

I used MLS as examples, but I'd expect all MAC systems will have similar 
issues, i.e. MAC aware applications should not do things which are in 
conflicts with MAC policies in other parts of the system. I think the 
"interference" of CALIPSO DOI on application protocols comes from the 
fact that labeled NFSv4 wants to reuse CALIPSO DOI for something different.

>   
>> DOI value      Opaque Security Attribute Field
>> ---------      -------------------------------
>>    1          CALIPSO MLS label using label encodings shared by A, B
>>    2          CALIPSO MLS label using label encodings shared by C, D
>>    3          Redhat DTE label using security policy shared by A, B
>>    4          OpenSolaris FMAC DTE label using sec policy shared by C, D
>>    5          BSD's Biba label using security policy shared by C, D
>>   ....
>>
>> In an MLS example, server host C gets a request from client host A with 
>> DOI = 1, requester label = CONFIDENTIAL. The client wants to write to 
>> file foo, which is protected by label INTERNAL under DOI 2. Server C 
>> validates that CONFIDENTIAL is a defined label in label encodings under 
>> DOI 1. It then translates the label and concludes that CONFIDENTIAL in 
>> DOI 1 is equivalent to INTERNAL in DOI 2, it then grants the write 
>> access to object foo (note in MLS, write access requires labels being 
>> equal).
>>     
>
> I think that's the sort of thing that David was aiming for, yes.
>
>   
>> I am having difficulty with how to manage DOIs with different 
>> combinations in the opaque field.
>>     
>
> I agree that it's best to have an encoding for the label than to leave
> it opaque.  I want a range of unknown DOIs with opque labels for
> extensibility though (see above).
>   

The difficulty is that label interpretation is directly tied to a label 
encoding file. Different organizations have control over content of this 
file. I don't know how you structure this with a protocol attribute.

>   
>>> A CALIPSO DOI is, AFAICT, a DOI that imposes an MLS form on the label
>>> (though with label encoding being protocol specific) and a security
>>> policy registration/definition requirement.  CALIPSO also requires that
>>> a DOI always be explicit.  CALIPSO also imposes a namespace of DOIs, and
>>> I'm not sure that it allows any DOIs that are not CALIPSO DOIs.  CALIPSO 
>>>
>>> In other words, any protocol that carries a {DOI ID, opaque label}
>>> should be compatible with CALIPSO.
>>>       
>
> I should have qualified that last statement: "any protocol that carries
> a {DOI ID, opaque label} _and can use MLS exclusively_ should be
> compatible with CALIPSO."
>
>   
>> Whenever a packet carries a CALIPSO label, explicit DOI is mandatory.
>>     
>
> David's I-D has that.
>
>   
>>> But an implementation that adheres to CALIPSO will not be able to use
>>> non-CALIPSO DOIs.  Is that correct?  If so we need to ensure that a
>>> mapping between MLS and DTE is possible, since David, IIRC, wants
>>> support for DTE.  But as far as I can tell such a mapping is possible.
>>>       
>> If labeled NFSv4 DOI is used to indicate how the opaque field should be 
>>     
>
> In David's I-D the encoding of the label is left to each DOI.  That's
> not unreasonable.  But in the face of CALIPSO we might as well specify
> an actual label encoding given that CALIPSO imposes label structure.
>   

This implies there is only one way to interpret a CALIPSO label. In fact 
every organization gets to say how a CALIPSO label should be 
interpreted. I don't see how a single DOI will make it work without some 
OOB agreement among communicating entities.


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.

Re: [nfsv4] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Thu, Mar 26, 2009 at 03:03:00PM -0700, Jarrett Lu wrote:
> CALIPSO spec doesn't tie a DOI with a particular label encoding. For 

CALIPSO is very specific about label domination -- that means that
having any application protocol w/ labeling above IP requires that we be
able to determine whether an application-level label is dominated by a
CALIPSO label, and the rules given are MLS with Bell-LaPadula.

Perhaps that does not mean that we must adopt MLS and Bell-LaPadula at
the application layer, but it certainly seems like the easiest path,
particularly if we can also represent DTE that way.

Now, CALIPSO does not impose a label _encoding_ (layout of bits on the
_wire_) outside IP, but it does seem to impose label _structure_ outside
of IP (see above).

> example, it DOI 1000 doesn't have to mean it's CALIPSO label with this 
> label encoding file. DOI 1000 could very well be used by SELinux systems 
> using a particular MAC policy. CALIPSO DOI does imply that when a node 
> can communicate with a DOI, it knows how to interpret the labels 
> associated with the DOI. All nodes using the same DOI have agreed on 
> what format and encodings to use. The agreement takes place else where, 
> most likely an administrative decision. Does labeled NFSv4 aim to 
> establish this agreement within the protocol itself?

As I read it CALIPSO allows each DOI to determine the names and meanings
of sensitivity levels, compartments, and releasability.  It does not
allow DOIs to impose a different label structure involving things other
than those (and the DOI number itself).

What exactly is your comment re: David's I-D?  I thought it was "opaque
is bad" but now I think you're saying the opposite.  I'm confused :)

I think partly the confusion relates to the word "encoding" (see below).

> >Also, this does not mean that the label shouldn't be opaque in the XDR
> >sense.  Using opaque in the XDR sense but actually imposing a label
> >encoding might still be desirable (mostly for compression, but also if
> >we should reserve some of the DOI number space for as-yet-unspecified
> >label structures and encodings).
> 
> CALIPSO spec reserves DOI value 1 - 255 for private use. If an 
> organization doesn't want to do labeled communication outside its 
> control, it can use a number in that range, without need to register 
> with IANA.

Indeed, but it still imposes label structure on private use DOIs, at
least as far as I can tell.  Did I misread CALIPSO?

> >Yes, and there's a relationship to the application data.  Thus, for
> >example, the label used for packets carrying NFS traffic has to
> >dominate the labels of the files being accessed via NFS.
> 
> Typically, SECRET data/file traffic doesn't leave SECRET network. So 
> labels in different layers/subsystems should match. What must not happen 
> is SECRET data flowing through UNCLASSIFIED network. In other words, we 
> don't want to see a request coming in from UNCLASIFFIED  interface 
> asking for SECRET files.

I think you've restated what I wrote.  I was arguing that this
requirement imposes CALIPSO's label structure (DOI, sensitivity level,
compartments and releasability) on the applications layered above IP.
Perhaps that's wrong.  This matter is one we're going to have to decide
before long.

> >CALIPSO imposes structure on labels, not encoding (it does define an
> >encoding for use in IPsec though).  The structure is: DOI, sensitivity
> >level, compartments, releasability.  We'll need to pick an encoding.
> 
> By label encoding, I mean how a CALIPSO label represented in a more 

Fine, but when talking about protocols with bits on the wire "encoding"
generally means "the format of the bits on the wire," so that's how I've
been using the term.

> basic form (e.g. hex or binary). It's usually done in a file, e.g. 
> 0x000300a0000 translates to SECRET and it dominates 0x0001007000. 
> Security administrators control the encoding. They get to say what 
> labels are valid and how valid label relate to each other on their 
> systems. Given this kind of local control, I don't know how we, who 
> defined protocol attributes, could pick one. The way it works is that 
> they (administrators) picked one, and agreed among themselves what label 
> encoding and DOI to use.

CALIPSO certainly specifies an encoding for use on the wire (see setion
5.1 of draft-stjohns-sipso-11).  If CALIPSO can, so can we.  The encoding
on the file system, the translation to human readable strings, the
semantics of each sensitivity level and compartment -- these are all
things that are specific to each DOI's rules.

> >David seems to want explicit support for DTE.  If we can get away with a
> >combination of MLS (and, maybe, privileges) to represent DTE then we can
> >stick exclusively to MLS and remain compliant with CALIPSO.  Given the
> >impact that CALIPSO has on application protocols I think we have no
> >choice (see above).
> 
> I used MLS as examples, but I'd expect all MAC systems will have similar 
> issues, i.e. MAC aware applications should not do things which are in 
> conflicts with MAC policies in other parts of the system. I think the 
> "interference" of CALIPSO DOI on application protocols comes from the 
> fact that labeled NFSv4 wants to reuse CALIPSO DOI for something different.

David's I-D doesn't even mention CALIPSO, so I don't see how you could
think that :)

> >I agree that it's best to have an encoding for the label than to leave
> >it opaque.  I want a range of unknown DOIs with opque labels for
> >extensibility though (see above).
> 
> The difficulty is that label interpretation is directly tied to a label 
> encoding file. Different organizations have control over content of this 
> file. I don't know how you structure this with a protocol attribute.

Then it seems to me that you have a comment to make on CALIPSO since it
imposes label structure and an encoding on the wire.

> >In David's I-D the encoding of the label is left to each DOI.  That's
> >not unreasonable.  But in the face of CALIPSO we might as well specify
> >an actual label encoding given that CALIPSO imposes label structure.
> 
> This implies there is only one way to interpret a CALIPSO label. In fact 
> every organization gets to say how a CALIPSO label should be 
> interpreted. I don't see how a single DOI will make it work without some 
> OOB agreement among communicating entities.

No, I don't think so.  I think we're each using "encoding" to mean
something different than the other is.  I'm talking strictly about bits
on the wire, not about interpretation (beyond the basic rules imposed by
CALIPSO), and not what Solaris TX means by label encoding.

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.

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Stephen Smalley]

On Thu, 2009-03-26 at 19:11 -0500, Nicolas Williams wrote:
> On Thu, Mar 26, 2009 at 03:03:00PM -0700, Jarrett Lu wrote:
> > CALIPSO spec doesn't tie a DOI with a particular label encoding. For 
> 
> CALIPSO is very specific about label domination -- that means that
> having any application protocol w/ labeling above IP requires that we be
> able to determine whether an application-level label is dominated by a
> CALIPSO label, and the rules given are MLS with Bell-LaPadula.
> 
> Perhaps that does not mean that we must adopt MLS and Bell-LaPadula at
> the application layer, but it certainly seems like the easiest path,
> particularly if we can also represent DTE that way.

You can't represent Type Enforcement via MLS/BLP; TE is strictly more
expressive than BLP, not the other way around.  It also has no inherent
notion of dominance; the access matrix is explicitly defined and may
include intransitive relationships, which are required for integrity
goals and guaranteed invocation.

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

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Stephen Smalley]

On Fri, 2009-03-27 at 08:55 -0400, Stephen Smalley wrote:
> On Thu, 2009-03-26 at 19:11 -0500, Nicolas Williams wrote:
> > On Thu, Mar 26, 2009 at 03:03:00PM -0700, Jarrett Lu wrote:
> > > CALIPSO spec doesn't tie a DOI with a particular label encoding. For 
> > 
> > CALIPSO is very specific about label domination -- that means that
> > having any application protocol w/ labeling above IP requires that we be
> > able to determine whether an application-level label is dominated by a
> > CALIPSO label, and the rules given are MLS with Bell-LaPadula.
> > 
> > Perhaps that does not mean that we must adopt MLS and Bell-LaPadula at
> > the application layer, but it certainly seems like the easiest path,
> > particularly if we can also represent DTE that way.
> 
> You can't represent Type Enforcement via MLS/BLP; TE is strictly more
> expressive than BLP, not the other way around.  It also has no inherent
> notion of dominance; the access matrix is explicitly defined and may
> include intransitive relationships, which are required for integrity
> goals and guaranteed invocation.

Also, in the case of SELinux and FMAC, the security context is more than
just a domain/type; it contains all of the security attributes relevant
to the security policy model, which in the case of the example security
server includes a user identity, a role, a domain/type, and a MLS range
(optionally just a single MLS level in the degenerate case where low ==
high).  But as far as the protocols are concerned, the entire security
context is just an opaque string.

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

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

Stephen Smalley wrote:
> On Fri, 2009-03-27 at 08:55 -0400, Stephen Smalley wrote:
>   
>> On Thu, 2009-03-26 at 19:11 -0500, Nicolas Williams wrote:
>>     
>>> On Thu, Mar 26, 2009 at 03:03:00PM -0700, Jarrett Lu wrote:
>>>       
>>>> CALIPSO spec doesn't tie a DOI with a particular label encoding. For 
>>>>         
>>> CALIPSO is very specific about label domination -- that means that
>>> having any application protocol w/ labeling above IP requires that we be
>>> able to determine whether an application-level label is dominated by a
>>> CALIPSO label, and the rules given are MLS with Bell-LaPadula.
>>>
>>> Perhaps that does not mean that we must adopt MLS and Bell-LaPadula at
>>> the application layer, but it certainly seems like the easiest path,
>>> particularly if we can also represent DTE that way.
>>>       
>> You can't represent Type Enforcement via MLS/BLP; TE is strictly more
>> expressive than BLP, not the other way around.  It also has no inherent
>> notion of dominance; the access matrix is explicitly defined and may
>> include intransitive relationships, which are required for integrity
>> goals and guaranteed invocation.
>>     
>
> Also, in the case of SELinux and FMAC, the security context is more than
> just a domain/type; it contains all of the security attributes relevant
> to the security policy model, which in the case of the example security
> server includes a user identity, a role, a domain/type, and a MLS range
> (optionally just a single MLS level in the degenerate case where low ==
> high).  But as far as the protocols are concerned, the entire security
> context is just an opaque string.
>
>   

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.


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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

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.

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Fri, Mar 27, 2009 at 11:56:41AM -0700, Jarrett Lu wrote:
> 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".

Well, you could use a PKIX certificate extension, or a Kebreros V ticket
authorization-data and ticket extension to point to the actual DOI
rules.

But the simplest thing, given that most nodes will participate in a
single DOI, is to configure this when the node joins the network (when
it gets whatever credentials it needs).  In practice this is exactly
what happens -- out of band delivery of what Solaris TX calls "label
encodings."

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

BTW, you're using the Solaris TX meaning of "label encoding" but CALIPSO
uses the term "encoding" in a very different way (or two: one in
relation to how to represent releasability, and the other for actual
bits on the wire).  We should be careful to use terminology that we all
understand.  What you've been calling "label encoding" CALIPSO calls, I
think, "a particular set of policies which define the Sensitivity Levels
and Compartments present within the DOI, and by inference, to the "real
world" (e.g. used on paper documents) equivalent labels" -- very wordy,
that!

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

I agree.  I believe that negotiation of the "particular set of policies
which..." is something that belongs in the authentication facilities, or
else out of band -- either way that is completely outside the scope of
this document (and even the RPCSEC_GSSv3 document).

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

Indeed.  What CALIPSO does though, is require that end-points select
packet labels that dominate the labels of the data being sent.

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.

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Fri, Mar 27, 2009 at 09:22:42AM -0400, Stephen Smalley wrote:
> On Fri, 2009-03-27 at 08:55 -0400, Stephen Smalley wrote:
> > You can't represent Type Enforcement via MLS/BLP; TE is strictly more
> > expressive than BLP, not the other way around.  It also has no inherent
> > notion of dominance; the access matrix is explicitly defined and may
> > include intransitive relationships, which are required for integrity
> > goals and guaranteed invocation.

I thought that MLS compartment -> DTE type.  Is that not the case?  I
realize that DTE does not have an inherent notion of dominance, but for
_documents_ (as opposed to operating system- or application-specific
files like /etc/shadow) there surely must be a way to establish
dominance, no?  That seems important to me.

> Also, in the case of SELinux and FMAC, the security context is more than
> just a domain/type; it contains all of the security attributes relevant
> to the security policy model, which in the case of the example security
> server includes a user identity, a role, a domain/type, and a MLS range
> (optionally just a single MLS level in the degenerate case where low ==
> high).  But as far as the protocols are concerned, the entire security
> context is just an opaque string.

My RPCSEC_GSSv3 proposal allows the client to make assertions about the
local process credentials of the process on whose behalf the client is
acting.  Things like identity, group memberships, privileges, audit
context, etcetera.  (Obviously the server has to evaluate what weight to
give those assertions given the client's and the user's authenticated
identities.)

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.

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Casey Schaufler]

Jarrett Lu wrote:
> Stephen Smalley wrote:
>   
>> On Fri, 2009-03-27 at 08:55 -0400, Stephen Smalley wrote:
>>   
>>     
>>> On Thu, 2009-03-26 at 19:11 -0500, Nicolas Williams wrote:
>>>     
>>>       
>>>> On Thu, Mar 26, 2009 at 03:03:00PM -0700, Jarrett Lu wrote:
>>>>       
>>>>         
>>>>> CALIPSO spec doesn't tie a DOI with a particular label encoding. For 
>>>>>         
>>>>>           
>>>> CALIPSO is very specific about label domination -- that means that
>>>> having any application protocol w/ labeling above IP requires that we be
>>>> able to determine whether an application-level label is dominated by a
>>>> CALIPSO label, and the rules given are MLS with Bell-LaPadula.
>>>>
>>>> Perhaps that does not mean that we must adopt MLS and Bell-LaPadula at
>>>> the application layer, but it certainly seems like the easiest path,
>>>> particularly if we can also represent DTE that way.
>>>>       
>>>>         
>>> You can't represent Type Enforcement via MLS/BLP; TE is strictly more
>>> expressive than BLP, not the other way around.  It also has no inherent
>>> notion of dominance; the access matrix is explicitly defined and may
>>> include intransitive relationships, which are required for integrity
>>> goals and guaranteed invocation.
>>>     
>>>       
>> Also, in the case of SELinux and FMAC, the security context is more than
>> just a domain/type; it contains all of the security attributes relevant
>> to the security policy model, which in the case of the example security
>> server includes a user identity, a role, a domain/type, and a MLS range
>> (optionally just a single MLS level in the degenerate case where low ==
>> high).  But as far as the protocols are concerned, the entire security
>> context is just an opaque string.
>>
>>   
>>     
>
> 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.

It is not. Two SELinux systems of the same version of the same
operating system may have different and incompatible policies.
Domains with the exact same name, intended for the exact same
purpose, may include MLS on one and MCS on the other, have
identical on wire representation of the labels, and still not
inter operate in any sane way. The same is true for Smack, where
the label Fish can be treated very differently on two adjacent
boxes. Any system that relies on opaque data is going to
have this problem, which is why the 1980's attempt at CIPSO
went down in flames.

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

Common label encoding isn't sufficient either. Consider two
computers, one encoded for DoD labels and the other for DoE
labels. Both use SECRET, and any attempt to translate between
the two will undoubtedly match them up even though they are
very different. The Mitre encoding scheme doesn't solve the
problem either, which is evident by the fact we're still
discussing the issue today.

What will work is the real question. The only notion I've seen
that really addresses the issue has been rejected many times
for the simple reason that it's too hard to administer. It
requires that each system have a map of all labels that it
expects to see from a given peer and their corresponding local
representations. Whoever figures out a reasonable way to go
about doing this gets a beer from me.



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

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Glenn Faden]

Casey Schaufler wrote:
> 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.
>>     
>
> It is not. Two SELinux systems of the same version of the same
> operating system may have different and incompatible policies.
> Domains with the exact same name, intended for the exact same
> purpose, may include MLS on one and MCS on the other, have
> identical on wire representation of the labels, and still not
> inter operate in any sane way. The same is true for Smack, where
> the label Fish can be treated very differently on two adjacent
> boxes. Any system that relies on opaque data is going to
> have this problem, which is why the 1980's attempt at CIPSO
> went down in flames.
>   
Casey I agree with you up to the last sentence. CIPSO was invented in 
the early 90's and is still in use today by multiple vendors. CALIPSO is 
essentially an IPv6 version of CIPSO.

I think your point is that neither CIPSO nor CALIPSO can be used to 
represent SELinux security contexts. If so, that should be obvious.

Your assertion that it is required for the client and server  to have 
the same policies and OS versions is generally true, although each 
system would be expected to refuse to deal with any types that is 
doesn't understand. The opportunity for misunderstanding seems likely. I 
have an additional concern how different systems, like SELinux and 
Solaris with FMAC will handle each other's security contexts. Even if 
their policies use the same types, roles, MLS labels, etc, the 
implementation details, like privileges vs. capabilities, will probably 
differ.
>   
>>  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.
>>   
>>     
>
> Common label encoding isn't sufficient either. Consider two
> computers, one encoded for DoD labels and the other for DoE
> labels. Both use SECRET, and any attempt to translate between
> the two will undoubtedly match them up even though they are
> very different. The Mitre encoding scheme doesn't solve the
> problem either, which is evident by the fact we're still
> discussing the issue today.
>
> What will work is the real question. The only notion I've seen
> that really addresses the issue has been rejected many times
> for the simple reason that it's too hard to administer. It
> requires that each system have a map of all labels that it
> expects to see from a given peer and their corresponding local
> representations. Whoever figures out a reasonable way to go
> about doing this gets a beer from me.
>
>   
In ancient times (the 1990s), trusted systems used to try to 
interoperate using the TSIX protocol. For those who want the history 
lesson here are the SGI and Sun docs:

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/cat7/trusted_networking.z

http://docs.sun.com/app/docs/doc/816-1048/6m7gaddhs?a=view

Sun dropped support for TSIX after all the other vendors withdrew from 
the market. The TSIX implementation was a mess, but it attempted to map 
one vendor's security attributes, e.g. privileges, into its own notion, 
e.g. capabilities. Labels were sent as strings and translated into local 
formats, as well. We sort of got it to work with Digital's MLS system, 
but everybody eventually fell back to CIPSO.

--Glenn


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

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Casey Schaufler]

Glenn Faden wrote:
> Casey Schaufler wrote:
>> 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.
>>>     
>>
>> It is not. Two SELinux systems of the same version of the same
>> operating system may have different and incompatible policies.
>> Domains with the exact same name, intended for the exact same
>> purpose, may include MLS on one and MCS on the other, have
>> identical on wire representation of the labels, and still not
>> inter operate in any sane way. The same is true for Smack, where
>> the label Fish can be treated very differently on two adjacent
>> boxes. Any system that relies on opaque data is going to
>> have this problem, which is why the 1980's attempt at CIPSO
>> went down in flames.
>>   
> Casey I agree with you up to the last sentence. CIPSO was invented in
> the early 90's 

Nope. Gary Winnegar (spelling?) had proposals out to TSIG by 1987.
That version was rejected out of hand.

> and is still in use today by multiple vendors.

The current version differs in that it is less flexible than
the original, and that is precisely aimed at IETF acceptability.

> CALIPSO is essentially an IPv6 version of CIPSO.
>
> I think your point is that neither CIPSO nor CALIPSO can be used to
> represent SELinux security contexts. If so, that should be obvious.

Actually, no. Either can be, provided the machines on both ends
have identical policy. The point is that you can't count on it
based on the information available.

>
> Your assertion that it is required for the client and server  to have
> the same policies and OS versions is generally true, although each
> system would be expected to refuse to deal with any types that is
> doesn't understand. The opportunity for misunderstanding seems likely.
> I have an additional concern how different systems, like SELinux and
> Solaris with FMAC will handle each other's security contexts. Even if
> their policies use the same types, roles, MLS labels, etc, the
> implementation details, like privileges vs. capabilities, will
> probably differ.
>>  
>>>  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.
>>>       
>>
>> Common label encoding isn't sufficient either. Consider two
>> computers, one encoded for DoD labels and the other for DoE
>> labels. Both use SECRET, and any attempt to translate between
>> the two will undoubtedly match them up even though they are
>> very different. The Mitre encoding scheme doesn't solve the
>> problem either, which is evident by the fact we're still
>> discussing the issue today.
>>
>> What will work is the real question. The only notion I've seen
>> that really addresses the issue has been rejected many times
>> for the simple reason that it's too hard to administer. It
>> requires that each system have a map of all labels that it
>> expects to see from a given peer and their corresponding local
>> representations. Whoever figures out a reasonable way to go
>> about doing this gets a beer from me.
>>
>>   
> In ancient times (the 1990s), trusted systems used to try to
> interoperate using the TSIX protocol. For those who want the history
> lesson here are the SGI and Sun docs:
>
> http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/cat7/trusted_networking.z
>
>
> http://docs.sun.com/app/docs/doc/816-1048/6m7gaddhs?a=view
>

Think IPSEC designed by people who thought B2 and CMW were good ideas.

> Sun dropped support for TSIX after all the other vendors withdrew from
> the market. The TSIX implementation was a mess, but it attempted to
> map one vendor's security attributes, e.g. privileges, into its own
> notion, e.g. capabilities. Labels were sent as strings and translated
> into local formats, as well. We sort of got it to work with Digital's
> MLS system, but everybody eventually fell back to CIPSO.

Yup.


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

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Stephen Smalley]

On Fri, 2009-03-27 at 17:09 -0500, Nicolas Williams wrote:
> On Fri, Mar 27, 2009 at 09:22:42AM -0400, Stephen Smalley wrote:
> > On Fri, 2009-03-27 at 08:55 -0400, Stephen Smalley wrote:
> > > You can't represent Type Enforcement via MLS/BLP; TE is strictly more
> > > expressive than BLP, not the other way around.  It also has no inherent
> > > notion of dominance; the access matrix is explicitly defined and may
> > > include intransitive relationships, which are required for integrity
> > > goals and guaranteed invocation.
> 
> I thought that MLS compartment -> DTE type.  Is that not the case?  I
> realize that DTE does not have an inherent notion of dominance, but for
> _documents_ (as opposed to operating system- or application-specific
> files like /etc/shadow) there surely must be a way to establish
> dominance, no?  That seems important to me.

No, there just needs to be a way to establish authorization.  The
internal logic for determining whether data of a given label is allowed
to transit over a network interface of a given label is policy-specific
and shouldn't be limited to the dominance relation.  It can just be
represented as a permission check on a label pair for a given object
class, and then the security policy logic can internally decide yes/no
on that permission based on any combination of the dominance relation,
the TE access matrix, or any other policy constraints.

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Stephen Smalley]

On Fri, 2009-03-27 at 11:56 -0700, Jarrett Lu wrote:
> 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.

I'm not sure if this conflicts with what you are saying, but the DOI
should merely identify the (externally) agreed-upon network label space
for the data to be shared between the communicating systems.  That label
space shouldn't need to be identical to the native/host label spaces of
any of the individual systems; they just need to have a way of mapping
between their host label spaces and the network label space identified
by the DOI in a manner that preserves their security goals.  The two
systems shouldn't necessarily have to share a label encodings file or
security policy configuration in order to communicate using a given DOI.

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

[-- Attachment #1: Type: text/plain, Size: 4622 bytes --]

On 03/30/09 10:37, Stephen Smalley wrote:
> On Fri, 2009-03-27 at 11:56 -0700, Jarrett Lu wrote:
>   
>> 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.
>>     
>
> I'm not sure if this conflicts with what you are saying, but the DOI
> should merely identify the (externally) agreed-upon network label space
> for the data to be shared between the communicating systems.  That label
> space shouldn't need to be identical to the native/host label spaces of
> any of the individual systems; they just need to have a way of mapping
> between their host label spaces and the network label space identified
> by the DOI in a manner that preserves their security goals.  The two
> systems shouldn't necessarily have to share a label encodings file or
> security policy configuration in order to communicate using a given DOI.
>
>   

As Casey and others pointed out, a lot more information about a 
communicating peer is needed in order to be able to translate a label 
and other security attributes. People have tried this in 90's. 
Apparently the solution is no longer in use today. Maybe we can do 
something better 15 years later. The first step is to figure out how 
much information is needed and then look into how to get this info 
across securely. GSS_SEC may be able to help us. To make NFSv4 work, 
only TCP is needed. So peer information is needed per session vs. per 
packet, I believe. Evidently, there is more work to do in figuring this 
all out.

A process related question: Should we move the "design" related 
discussion to a smaller alias? I assume most people don't care about the 
details and prefer not see this in their email inbox. I set up a mail 
alias, doi-discuss@opensolaris.org, a few months ago for a similar 
discussion. If people think that's a good way to go, I can provide more 
info.

Jarrett

[-- Attachment #2: Type: text/html, Size: 5149 bytes --]

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Mon, Mar 30, 2009 at 11:30:25AM -0700, Jarrett Lu wrote:
> On 03/30/09 10:37, Stephen Smalley wrote:
> >I'm not sure if this conflicts with what you are saying, but the DOI
> >should merely identify the (externally) agreed-upon network label space
> >for the data to be shared between the communicating systems.  [...]

Right now that's the best we can do, and CALIPSO does nothing to improve
this situation.

> As Casey and others pointed out, a lot more information about a 
> communicating peer is needed in order to be able to translate a label 
> and other security attributes. People have tried this in 90's. 
> Apparently the solution is no longer in use today. Maybe we can do 
> something better 15 years later. The first step is to figure out how 
> much information is needed and then look into how to get this info 
> across securely. GSS_SEC may be able to help us. To make NFSv4 work, 
> only TCP is needed. So peer information is needed per session vs. per 
> packet, I believe. Evidently, there is more work to do in figuring this 
> all out.

I believe that certificate extensions and Kerberos V authorization-data
could be used to ensure that the client and server both know the correct
"label encodings" for their shared DOIs.

To specify such a thing would be easy: allocate cert ext OID (for PKIX
certs) and authz-data ID (for Kebreros V) and specify the contents of
the extension, which could be the DER encoding of:

	DOI-SPEC ::= SEQUENCE {
		doi INTEGER (0..MAX),
		label-encodings-uri UTF8STRING -- contraint: MUST be a URI
	}

	DOI-SPECS ::= SEQUENCE SIZE (1..MAX) OF DOI-SPEC;

I.e., a sequence of {DOI number, label encodings URI}.

Then define the format of the document referenced by the label encodings
URI.  That format should cover MLS and DTE DOI types.

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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Mon, Mar 30, 2009 at 03:01:21PM -0500, Nicolas Williams wrote:
> I believe that certificate extensions and Kerberos V authorization-data
> could be used to ensure that the client and server both know the correct
> "label encodings" for their shared DOIs.

Of course, this does nothing for deployments that don't use PKIX or
Kerberos V.  We can do something like this for all trusted third-party
distributed authentication systems.  But for simple pre-shared key (PSK)
and simpler schemes (e.g., AUTH_SYS) there's nothing we can do: the
client and server will have to agree on a DOI and label encodings a
priori.

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

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Mon, Mar 30, 2009 at 12:51:48PM -0400, Stephen Smalley wrote:
> On Fri, 2009-03-27 at 17:09 -0500, Nicolas Williams wrote:
> > On Fri, Mar 27, 2009 at 09:22:42AM -0400, Stephen Smalley wrote:
> > > On Fri, 2009-03-27 at 08:55 -0400, Stephen Smalley wrote:
> > > > You can't represent Type Enforcement via MLS/BLP; TE is strictly more
> > > > expressive than BLP, not the other way around.  It also has no inherent
> > > > notion of dominance; the access matrix is explicitly defined and may
> > > > include intransitive relationships, which are required for integrity
> > > > goals and guaranteed invocation.
> > 
> > I thought that MLS compartment -> DTE type.  Is that not the case?  I
> > realize that DTE does not have an inherent notion of dominance, but for
> > _documents_ (as opposed to operating system- or application-specific
> > files like /etc/shadow) there surely must be a way to establish
> > dominance, no?  That seems important to me.
> 
> No, there just needs to be a way to establish authorization.  The
> internal logic for determining whether data of a given label is allowed
> to transit over a network interface of a given label is policy-specific
> and shouldn't be limited to the dominance relation.  It can just be
> represented as a permission check on a label pair for a given object
> class, and then the security policy logic can internally decide yes/no
> on that permission based on any combination of the dominance relation,
> the TE access matrix, or any other policy constraints.

OK, good -- that's a local-to-end-points consideration, so we can keep
the use of DTE at the end-to-end application layer and CALIPSO at the IP
layer compatible.

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Stephen Smalley]

On Mon, 2009-03-30 at 11:30 -0700, Jarrett Lu wrote:
> On 03/30/09 10:37, Stephen Smalley wrote: 
> > On Fri, 2009-03-27 at 11:56 -0700, Jarrett Lu wrote:
> >   
> > > 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.
> > >     
> > 
> > I'm not sure if this conflicts with what you are saying, but the DOI
> > should merely identify the (externally) agreed-upon network label space
> > for the data to be shared between the communicating systems.  That label
> > space shouldn't need to be identical to the native/host label spaces of
> > any of the individual systems; they just need to have a way of mapping
> > between their host label spaces and the network label space identified
> > by the DOI in a manner that preserves their security goals.  The two
> > systems shouldn't necessarily have to share a label encodings file or
> > security policy configuration in order to communicate using a given DOI.
> > 
> >   
> 
> As Casey and others pointed out, a lot more information about a
> communicating peer is needed in order to be able to translate a label
> and other security attributes.

Yes, but the DOI is all that NFSv4 needs to convey in order to identify
that (external) information (i.e. the DOI is the key/identifier by which
the receiving system looks up the right set of translation/mapping
functions for dealing with the network label space associated with the
DOI, where the translation/mapping functions are configured via
information established OOB to NFSv4 itself).  Defining precisely how
that external information gets populated is IMHO out of scope for
NFSv4. 

>  People have tried this in 90's. Apparently the solution is no longer
> in use today. Maybe we can do something better 15 years later. The
> first step is to figure out how much information is needed and then
> look into how to get this info across securely. GSS_SEC may be able to
> help us. To make NFSv4 work, only TCP is needed. So peer information
> is needed per session vs. per packet, I believe. Evidently, there is
> more work to do in figuring this all out.
> 
> A process related question: Should we move the "design" related
> discussion to a smaller alias? I assume most people don't care about
> the details and prefer not see this in their email inbox. I set up a
> mail alias, doi-discuss@opensolaris.org, a few months ago for a
> similar discussion. If people think that's a good way to go, I can
> provide more info.

Seems like it just becomes one more list that people have to follow to
get the whole picture for labeled NFS.

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Casey Schaufler]

Jarrett Lu wrote:
> ...
> As Casey and others pointed out, a lot more information about a
> communicating peer is needed in order to be able to translate a label
> and other security attributes. People have tried this in 90's.
> Apparently the solution is no longer in use today.

You're giving us more credit than we're due. No, the problem was never
solved. Oh, we had a few "interoperability rings", where we got together
and tried talking CIPSO and SAMP to each other, but it was sort of like
going to a SciFi convention and striking up conversations in Klingon.
I believe that DEC claimed they could talk to SUN using SAMP and HP
could talk to SGI in CIPSO, and everyone could banter in their own
version of NFS, but there was no money behind it, and interoperability
was never achieved even at the low levels.

> Maybe we can do something better 15 years later. The first step is to
> figure out how much information is needed and then look into how to
> get this info across securely. GSS_SEC may be able to help us. To make
> NFSv4 work, only TCP is needed. So peer information is needed per
> session vs. per packet, I believe. Evidently, there is more work to do
> in figuring this all out.

Not to throw a puppy in the gears, but sophisticated handshaking and
negotiation protocols are not the answer. We had TSIG session management
for doing that and it is just not enough. How would you negotiate the
differences between two SELinux policies?

>
> A process related question: Should we move the "design" related
> discussion to a smaller alias? I assume most people don't care about
> the details and prefer not see this in their email inbox. I set up a
> mail alias, doi-discuss@opensolaris.org, a few months ago for a
> similar discussion. If people think that's a good way to go, I can
> provide more info.

I would be delighted to see the discussion stay here. I would expect
a smaller group to end up with a rehash of one of the TSIX protocols
and a chip on their shoulders to make it go because of the work that
had gone into it. The problem is not one of communication, it's one
of getting the information communicated to make sense. Look at CIFS
and NFSv4 ACLs. That is the level of effort you have to invest to
solve the problem for a pair of different security schemes. True,
the more similar the schemes the more likely the results will make
sense, but even two Smack systems with different rule sets, or
two TOMOYO boxes with different profiles are beyond what you can fit
in a configuration database.

NFSv4 with labels will properly only ever support servers and clients
with identical label configurations, and with that the DOI becomes
meaningless. If you want to support labels improperly you have a
much better chance of success, but a tougher row to hoe with the
standards bodies. This is hard, and we've been working since the 80's
on it, looking for someone smarter than us to propose a solution.


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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

Stephen Smalley wrote:
> On Mon, 2009-03-30 at 11:30 -0700, Jarrett Lu wrote:
>   
>> On 03/30/09 10:37, Stephen Smalley wrote: 
>>     
>>> On Fri, 2009-03-27 at 11:56 -0700, Jarrett Lu wrote:
>>>   
>>>       
>>>> 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.
>>>>     
>>>>         
>>> I'm not sure if this conflicts with what you are saying, but the DOI
>>> should merely identify the (externally) agreed-upon network label space
>>> for the data to be shared between the communicating systems.  That label
>>> space shouldn't need to be identical to the native/host label spaces of
>>> any of the individual systems; they just need to have a way of mapping
>>> between their host label spaces and the network label space identified
>>> by the DOI in a manner that preserves their security goals.  The two
>>> systems shouldn't necessarily have to share a label encodings file or
>>> security policy configuration in order to communicate using a given DOI.
>>>
>>>   
>>>       
>> As Casey and others pointed out, a lot more information about a
>> communicating peer is needed in order to be able to translate a label
>> and other security attributes.
>>     
>
> Yes, but the DOI is all that NFSv4 needs to convey in order to identify
> that (external) information (i.e. the DOI is the key/identifier by which
> the receiving system looks up the right set of translation/mapping
> functions for dealing with the network label space associated with the
> DOI, where the translation/mapping functions are configured via
> information established OOB to NFSv4 itself).  Defining precisely how
> that external information gets populated is IMHO out of scope for
> NFSv4. 
>   

That's certainly one option. We can say DOI + an opaque field is what we 
will add to NFSv4 protocol. Use the information as you see fit. Going 
this route, we basically punt on the label interpretation / translation 
problem. I believe this simple DOI + opaque attribute does add value as 
it provides an potentially easier way for compatible systems to 
communicate label attributes on file objects. I was trying to explore 
whether it makes sense to include other information (e.g. OS version, 
signature of security policy or label encoding files) to make handling 
of label interpretation and translation easier.


>   
>>  People have tried this in 90's. Apparently the solution is no longer
>> in use today. Maybe we can do something better 15 years later. The
>> first step is to figure out how much information is needed and then
>> look into how to get this info across securely. GSS_SEC may be able to
>> help us. To make NFSv4 work, only TCP is needed. So peer information
>> is needed per session vs. per packet, I believe. Evidently, there is
>> more work to do in figuring this all out.
>>
>> A process related question: Should we move the "design" related
>> discussion to a smaller alias? I assume most people don't care about
>> the details and prefer not see this in their email inbox. I set up a
>> mail alias, doi-discuss@opensolaris.org, a few months ago for a
>> similar discussion. If people think that's a good way to go, I can
>> provide more info.
>>     
>
> Seems like it just becomes one more list that people have to follow to
> get the whole picture for labeled NFS.
>
>   

Continuing on these lists is fine with me. People on these lists 
probably have high tolerance on postings that don't care about.


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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Paul Moore]

On Monday 30 March 2009 11:07:02 pm Casey Schaufler wrote:
> Jarrett Lu wrote:
> > Maybe we can do something better 15 years later. The first step is to
> > figure out how much information is needed and then look into how to
> > get this info across securely. GSS_SEC may be able to help us. To make
> > NFSv4 work, only TCP is needed. So peer information is needed per
> > session vs. per packet, I believe. Evidently, there is more work to do
> > in figuring this all out.
>
> Not to throw a puppy in the gears, but sophisticated handshaking and
> negotiation protocols are not the answer. We had TSIG session management
> for doing that and it is just not enough. How would you negotiate the
> differences between two SELinux policies?

I'm with Casey, I don't think it is worth spending a whole lot of time right 
now finding out how to pass information across the network in a secure manner.  
There are plenty of ways of to do that which are well established, 
interoperable and generally regarded as "secure".

>From my point of view the real issue is how do we translate/resolve security 
labels defined by DOI X to an internal, security model/policy specific label?  
Some have mentioned a mechanism which would serve up label encoding data 
whenever a new system joined the network; unfortunately, I believe this only 
works when you know the security policy of the system before hand (or can 
restrict the security policy, after all a TSOL label encodings file will do 
nothing for SELinux and/or Smack).  While I think it is reasonable to assume a 
limited number of on-the-wire label encodings and DOIs I think it would be a 
mistake to assume a limited number of security models and or policies.

Ultimately I believe that the required label translation information (wire/DOI 
label to internal and the other way around) is going to need to be bundled 
with the system's security policy and distributed as a single "package".  
Granted this does require prior knowledge of the DOIs in use but I believe 
this is a much easier requirement than the opposite.  From a practical point 
of view this isn't too far removed from the notion of sending sending label 
encoding data upon joining the network, the big difference is that we are 
sending both security policy and label encoding/DOI-translation data at the 
same time (in the TSOL case I suspect this would just be the label encoding 
data, which may mean the original poster had this in mind).

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Mon, Mar 30, 2009 at 10:59:15PM -0700, Jarrett Lu wrote:
> That's certainly one option. We can say DOI + an opaque field is what we 
> will add to NFSv4 protocol. Use the information as you see fit. Going 

That's what David's I-D and what my RPCSEC_GSSv3 I-D both say now.

It's also what CALIPSO does (except that the label must be MLS and the
bits on the wire are defined, though the actual sentivity levels and
compartment naming and mapping to bits is not).

> this route, we basically punt on the label interpretation / translation 
> problem. I believe this simple DOI + opaque attribute does add value as 
> it provides an potentially easier way for compatible systems to 
> communicate label attributes on file objects. I was trying to explore 
> whether it makes sense to include other information (e.g. OS version, 
> signature of security policy or label encoding files) to make handling 
> of label interpretation and translation easier.

Signature of security policy is certainly an interesting idea!  But it
does require defining a standard security policy description syntax --
that's work that I think is well outside what this WG should be working
on.  (Also, we'll need hash function agility.)

Therefore I think the NFSv4 community should stop at either

 - {DOI #, opaque label, hash function name, hash-of-policy}
   (which means blocking on a standards-track labeled policy document)

or, more likely,

 - {DOI #, opaque label, [extensibility field for future hash function
   name / hash-of-policy]}.

The latter seems better to me because {DOI #, opaque label} is the easy
way forward for this WG, but we'd make room for a future hash-of-policy.

I think the security area of the IETF should explore Kerberos V
authz-data and PKIX certificate extensions to ensure DOI label encoding
synchronization (whether based on my sketch or some other approach) as
well as a common labeled security policy syntax covering MLS and DTE.

I know, where each set of documents gets done is a subtle distinction
when it might well be the same people doing all of them.  But it's an
important distinction here.

Also, it's possible that some of this work will be done in the form of
individual submission I-Ds all the way if it doesn't naturally fit any
WG and we don't have enough work to justify spinning up a new WG.  But
we'd still seek review in the appropriate WGs (NFSv4 WG for NFS work,
KRB-WG for Kerberos work, PKIX WG for PKIX work, SAAG for labeled
security policy description).

(Between CALIPSO and NFSv4 and all the other potential work mentioned
above we might well have enough work for a new WG.  But I think we
should proceed as though we don't, for now.)

> Continuing on these lists is fine with me. People on these lists 
> probably have high tolerance on postings that don't care about.

It sure seems that way so far :)

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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Mon, Mar 30, 2009 at 08:07:02PM -0700, Casey Schaufler wrote:
> Not to throw a puppy in the gears, but sophisticated handshaking and
> negotiation protocols are not the answer. We had TSIG session management
> for doing that and it is just not enough. How would you negotiate the
> differences between two SELinux policies?

You don't.  You either establish that they are the same (or that one or
both peers are translating to a common policy) or that they are not.  In
the latter case you fail to communicate further.  It seems quite
reasonable to me to have a single policy for a site -- that seems doable
for MLS, but for DTE it's more likely that there will be OS-specific
parts of a site policy, and the potential need to map between existing
OS-specific policies and something else seems daunting, at least at
first glance, but I'm an optimist, so I think it must be doable :)

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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

Nicolas Williams wrote:
> On Mon, Mar 30, 2009 at 10:59:15PM -0700, Jarrett Lu wrote:
>   
>> That's certainly one option. We can say DOI + an opaque field is what we 
>> will add to NFSv4 protocol. Use the information as you see fit. Going 
>>     
>
> That's what David's I-D and what my RPCSEC_GSSv3 I-D both say now.
>   

If we stop here, we don't have much of an interoperability story. I 
thought it is one of the things we are aiming for. We can say "give us 
an opaque field and we (the MAC systems) will decide how and when to use 
it. NFSv4 WG and ADs still want to know how this opaque field may be 
used. They are less willing to hand out "opaque" field just because 
someone asked for one. At least this is the impression I got at IETF74 
in SF.

> It's also what CALIPSO does (except that the label must be MLS and the
> bits on the wire are defined, though the actual sentivity levels and
> compartment naming and mapping to bits is not).
>   

Right. This makes it easier for systems speaking CALIPSO protocol to 
interoperate at IP layer. Compliant hosts and routers know how to deal 
with packets with that option. Label translation between different DOIs 
is out of scope.

>   
>> this route, we basically punt on the label interpretation / translation 
>> problem. I believe this simple DOI + opaque attribute does add value as 
>> it provides an potentially easier way for compatible systems to 
>> communicate label attributes on file objects. I was trying to explore 
>> whether it makes sense to include other information (e.g. OS version, 
>> signature of security policy or label encoding files) to make handling 
>> of label interpretation and translation easier.
>>     
>
> Signature of security policy is certainly an interesting idea!  But it
> does require defining a standard security policy description syntax --
> that's work that I think is well outside what this WG should be working
> on.  (Also, we'll need hash function agility.)
>
> Therefore I think the NFSv4 community should stop at either
>
>  - {DOI #, opaque label, hash function name, hash-of-policy}
>    (which means blocking on a standards-track labeled policy document)
>
> or, more likely,
>
>  - {DOI #, opaque label, [extensibility field for future hash function
>    name / hash-of-policy]}.
>
> The latter seems better to me because {DOI #, opaque label} is the easy
> way forward for this WG, but we'd make room for a future hash-of-policy.
>   

I'm in general agreement with you on this. I am not sure to what extent 
the extensibility stuff makes sense, e.g. how much may be enough? I 
guess we need to study more use scenarios. I suspect TE systems may have 
more challenges in this area, just because security policies on TE 
systems tend to be more flexible. For example, how many things are 
critical in order to translate label correctly, OS version, vendor, 
label parser, security policy file? How likely DTE systems are 
configured with exact same policy files? Does it make sense that a 
(harmless) update to security policy file causes label translation 
failures from that point on?

> I think the security area of the IETF should explore Kerberos V
> authz-data and PKIX certificate extensions to ensure DOI label encoding
> synchronization (whether based on my sketch or some other approach) as
> well as a common labeled security policy syntax covering MLS and DTE.
>
> I know, where each set of documents gets done is a subtle distinction
> when it might well be the same people doing all of them.  But it's an
> important distinction here.
>
> Also, it's possible that some of this work will be done in the form of
> individual submission I-Ds all the way if it doesn't naturally fit any
> WG and we don't have enough work to justify spinning up a new WG.  But
> we'd still seek review in the appropriate WGs (NFSv4 WG for NFS work,
> KRB-WG for Kerberos work, PKIX WG for PKIX work, SAAG for labeled
> security policy description).
>
> (Between CALIPSO and NFSv4 and all the other potential work mentioned
> above we might well have enough work for a new WG.  But I think we
> should proceed as though we don't, for now.)
>   

No disagreement here either. At the end of this scoping exercise, we'll 
hopefully know how big a bite we can chew. I believe the DOI + opaque 
field may be useful to identical or compatible system under same 
administrative control. To push David's draft forward, I believe we 
still need to understand more about how different systems may use the 
opaque field and decide if it makes sense to propose extensibility 
fields for future use.


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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Casey Schaufler]

Nicolas Williams wrote:
> On Mon, Mar 30, 2009 at 08:07:02PM -0700, Casey Schaufler wrote:
>   
>> Not to throw a puppy in the gears, but sophisticated handshaking and
>> negotiation protocols are not the answer. We had TSIG session management
>> for doing that and it is just not enough. How would you negotiate the
>> differences between two SELinux policies?
>>     
>
> You don't.  You either establish that they are the same (or that one or
> both peers are translating to a common policy) or that they are not.  In
> the latter case you fail to communicate further.  It seems quite
> reasonable to me to have a single policy for a site -- that seems doable
> for MLS, but for DTE it's more likely that there will be OS-specific
> parts of a site policy, and the potential need to map between existing
> OS-specific policies and something else seems daunting, at least at
> first glance, but I'm an optimist, so I think it must be doable :)
>   

You only get common policy on a single system image. Oh, with MLS
you can limit it to MLS hosts and unlabeled hosts, but you'll always
have at least the two. Even with MLS you'll have machines that are
disallowed each other's levels and/or categories. This situation
had a major impact on the Smack design, where there is no interpretation
of the label at all.


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

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[James Morris]

On Tue, 31 Mar 2009, Jarrett Lu wrote:

> I'm in general agreement with you on this. I am not sure to what extent 
> the extensibility stuff makes sense, e.g. how much may be enough? I 
> guess we need to study more use scenarios. I suspect TE systems may have 
> more challenges in this area, just because security policies on TE 
> systems tend to be more flexible. For example, how many things are 
> critical in order to translate label correctly, OS version, vendor, 
> label parser, security policy file? How likely DTE systems are 
> configured with exact same policy files? Does it make sense that a 
> (harmless) update to security policy file causes label translation 
> failures from that point on?

With SELinux systems, policies do not need to be identical to be 
considered part of the same DOI.  Generally, labels need to remain 
semantically equivalent (i.e. mean the same thing on each system), and the 
policies need to be managed within the same administrative boundary. 
Systems may restrict which labels they'll interpret from remote systems 
(similar to root_squash).


- James
-- 
James Morris
<jmorris@namei.org>

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

[-- Attachment #1: Type: text/plain, Size: 4046 bytes --]

On 3/31/2009 7:47 AM, Paul Moore wrote:
> On Monday 30 March 2009 11:07:02 pm Casey Schaufler wrote:
>    
>> Jarrett Lu wrote:
>>      
>>> Maybe we can do something better 15 years later. The first step is to
>>> figure out how much information is needed and then look into how to
>>> get this info across securely. GSS_SEC may be able to help us. To make
>>> NFSv4 work, only TCP is needed. So peer information is needed per
>>> session vs. per packet, I believe. Evidently, there is more work to do
>>> in figuring this all out.
>>>        
>> Not to throw a puppy in the gears, but sophisticated handshaking and
>> negotiation protocols are not the answer. We had TSIG session management
>> for doing that and it is just not enough. How would you negotiate the
>> differences between two SELinux policies?
>>      
>
> I'm with Casey, I don't think it is worth spending a whole lot of time right
> now finding out how to pass information across the network in a secure manner.
> There are plenty of ways of to do that which are well established,
> interoperable and generally regarded as "secure".
>    

I'm not reinventing another secure way to pass information. I thought 
kerberos gss api may be a good candidate. I also agree that 
sophisticated handshaking negotiation protocol or complicated security 
attribute mapping between various systems is not the way to go.

>  From my point of view the real issue is how do we translate/resolve security
> labels defined by DOI X to an internal, security model/policy specific label?
> Some have mentioned a mechanism which would serve up label encoding data
> whenever a new system joined the network; unfortunately, I believe this only
> works when you know the security policy of the system before hand (or can
> restrict the security policy, after all a TSOL label encodings file will do
> nothing for SELinux and/or Smack).  While I think it is reasonable to assume a
> limited number of on-the-wire label encodings and DOIs I think it would be a
> mistake to assume a limited number of security models and or policies.
>    

True. The first question is whether we should try to solve, or at least 
ease, the label interpretation / translation problem in the context of 
NFSv4 protocol. I don't know if we can solve it, but it seems worthwhile 
to explore further, to gain more understanding if nothing else. The 
challenge of interpreting and translating labels is that one system 
needs to know a lot of info about its peer. And there is no good way to 
describe the (sometimes subtle) difference. I think this problem may be 
harder on DTE systems than on MLS systems, I believe.

> Ultimately I believe that the required label translation information (wire/DOI
> label to internal and the other way around) is going to need to be bundled
> with the system's security policy and distributed as a single "package".
> Granted this does require prior knowledge of the DOIs in use but I believe
> this is a much easier requirement than the opposite.  From a practical point
> of view this isn't too far removed from the notion of sending sending label
> encoding data upon joining the network, the big difference is that we are
> sending both security policy and label encoding/DOI-translation data at the
> same time (in the TSOL case I suspect this would just be the label encoding
> data, which may mean the original poster had this in mind).
>
>    

Depending how different the systems are, the "package" content will be 
different. Assuming we can assemble all the information required to do 
label translation correctly into a package, passing that around the 
systems seem inefficient, non-scalable, and probably outside the scope 
of labeled NFSv4 enhancement. So realistically, I think the DOI + opaque 
label is useful between very compatible systems. Given that limitation, 
may be the "package" is small enough and can be passed in RPC layer 
during authentication so that MLS can share files with like MLS systems, 
and same is true for DTE, fmac, smack, ....


Jarrett



[-- Attachment #2: Type: text/html, Size: 4723 bytes --]

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

On 3/31/2009 11:58 PM, James Morris wrote:
> On Tue, 31 Mar 2009, Jarrett Lu wrote:
>
>    
>> I'm in general agreement with you on this. I am not sure to what extent
>> the extensibility stuff makes sense, e.g. how much may be enough? I
>> guess we need to study more use scenarios. I suspect TE systems may have
>> more challenges in this area, just because security policies on TE
>> systems tend to be more flexible. For example, how many things are
>> critical in order to translate label correctly, OS version, vendor,
>> label parser, security policy file? How likely DTE systems are
>> configured with exact same policy files? Does it make sense that a
>> (harmless) update to security policy file causes label translation
>> failures from that point on?
>>      
>
> With SELinux systems, policies do not need to be identical to be
> considered part of the same DOI.  Generally, labels need to remain
> semantically equivalent (i.e. mean the same thing on each system), and the
> policies need to be managed within the same administrative boundary.
> Systems may restrict which labels they'll interpret from remote systems
> (similar to root_squash).
>
>    

Understood. My point is that a signature on a policy file may not always 
be the right tool to determine whether label translation should be done. 
When policies are different on two systems, how does one system know 
labels or types are semantically equivalent or not? Are you also saying 
that DOI is tied to administrative boundary, and the fact that systems 
using the same DOI implies the label and type definitions in each policy 
are always semantically equivalent?


Jarrett

> - James
>    


[-- Attachment #2: Type: text/html, Size: 2209 bytes --]

Re: [Labeled-nfs] [nfsv4] New MAC label support Internet Draft posted to IETF website

[James Morris]

On Wed, 1 Apr 2009, Jarrett Lu wrote:

> > With SELinux systems, policies do not need to be identical to be
> > considered part of the same DOI.  Generally, labels need to remain
> > semantically equivalent (i.e. mean the same thing on each system), and the
> > policies need to be managed within the same administrative boundary.
> > Systems may restrict which labels they'll interpret from remote systems
> > (similar to root_squash).
> > 
> >    
> 
> Understood. My point is that a signature on a policy file may not always be
> the right tool to determine whether label translation should be done. When
> policies are different on two systems, how does one system know labels or
> types are semantically equivalent or not?

This should be determined via the DOI.

> Are you also saying that DOI is tied
> to administrative boundary, and the fact that systems using the same DOI
> implies the label and type definitions in each policy are always semantically
> equivalent?

For DOIs designed to function like this, yes.  i.e. it's not a property 
inherent to DOIs, but of how they're administered.


- James
-- 
James Morris
<jmorris@namei.org>

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Paul Moore]

On Wednesday 01 April 2009 03:46:58 am Jarrett Lu wrote:
> On 3/31/2009 7:47 AM, Paul Moore wrote:
> > On Monday 30 March 2009 11:07:02 pm Casey Schaufler wrote:
> >> Jarrett Lu wrote:
> >>> Maybe we can do something better 15 years later. The first step is to
> >>> figure out how much information is needed and then look into how to
> >>> get this info across securely. GSS_SEC may be able to help us. To make
> >>> NFSv4 work, only TCP is needed. So peer information is needed per
> >>> session vs. per packet, I believe. Evidently, there is more work to do
> >>> in figuring this all out.
> >>
> >> Not to throw a puppy in the gears, but sophisticated handshaking and
> >> negotiation protocols are not the answer. We had TSIG session management
> >> for doing that and it is just not enough. How would you negotiate the
> >> differences between two SELinux policies?
> >
> > I'm with Casey, I don't think it is worth spending a whole lot of time
> > right now finding out how to pass information across the network in a
> > secure manner. There are plenty of ways of to do that which are well
> > established, interoperable and generally regarded as "secure".
>
> I'm not reinventing another secure way to pass information. I thought
> kerberos gss api may be a good candidate. I also agree that
> sophisticated handshaking negotiation protocol or complicated security
> attribute mapping between various systems is not the way to go.

My only comment was that figuring out how to transfer information over the 
network isn't really that important yet.  Reading through the thread I don't 
think there is general agreement on what we even need to send to enable proper 
label translation/encoding/etc.

> >  From my point of view the real issue is how do we translate/resolve
> > security labels defined by DOI X to an internal, security model/policy
> > specific label? Some have mentioned a mechanism which would serve up
> > label encoding data whenever a new system joined the network;
> > unfortunately, I believe this only works when you know the security
> > policy of the system before hand (or can restrict the security policy,
> > after all a TSOL label encodings file will do nothing for SELinux and/or
> > Smack).  While I think it is reasonable to assume a limited number of
> > on-the-wire label encodings and DOIs I think it would be a mistake to
> > assume a limited number of security models and or policies.
>
> True. The first question is whether we should try to solve, or at least
> ease, the label interpretation / translation problem in the context of
> NFSv4 protocol. I don't know if we can solve it, but it seems worthwhile
> to explore further, to gain more understanding if nothing else.

I've been trying to look at this problem in a more generic sense and not just 
from a labeled NFS point of view.  While the current pain point is labeled NFS 
the idea of label translation/encoding/etc is not exclusive to NFS or network 
filesystems in general; I'm sure we can all agree on this.  While we may need 
to solve (as best we can) the label translation issues on a per-application 
basis I really hope that we might be able to develop a solution which can be 
used across multiple applications and not just NFS.

> The challenge of interpreting and translating labels is that one system
> needs to know a lot of info about its peer. And there is no good way to
> describe the (sometimes subtle) difference. I think this problem may be
> harder on DTE systems than on MLS systems, I believe.

I'm not sure we will ever be able to arrive at a solution that requires a 
system to be able to understand the security policy/labels of another; things 
change to much and I don't think anyone's crystal ball is that good.  
Personally I think the best we can do is hope for a solution that allows a 
system to understand a security policy/label system defined by a pre-existing 
DOI definition.  If we can do that then we can at least allow two different 
systems to communicate via an agreed upon DOI regardless of their internal 
security policies/labels.  I'll admit it isn't perfect, but I think the 
problem space is much smaller and likely to have less churn over time.

> > Ultimately I believe that the required label translation information
> > (wire/DOI label to internal and the other way around) is going to need to
> > be bundled with the system's security policy and distributed as a single
> > "package". Granted this does require prior knowledge of the DOIs in use
> > but I believe this is a much easier requirement than the opposite.  From
> > a practical point of view this isn't too far removed from the notion of
> > sending sending label encoding data upon joining the network, the big
> > difference is that we are sending both security policy and label
> > encoding/DOI-translation data at the same time (in the TSOL case I
> > suspect this would just be the label encoding data, which may mean the
> > original poster had this in mind).
>
> Depending how different the systems are, the "package" content will be
> different.

Yep, that is the point; squares hole need square pegs, round holes need round 
pegs.

> Assuming we can assemble all the information required to do
> label translation correctly into a package, passing that around the
> systems seem inefficient, non-scalable ...

Honestly I don't see it as being that far removed from many of the current 
solutions that ship "security policy" to individual systems through the 
network/enterprise.  Also look at some of the NAC stuff that is being used 
these days, how is a security policy/translation "package" all that different 
from an anti-virus update or a set of os/application patches?

It is a solvable problem, or at least one that users have shown a willingness 
to tolerate.

> ... and probably outside the scope of labeled NFSv4 enhancement.

Perhaps.  Keep in mind I'm trying to think a bit more generically; if that 
isn't the goal I'll be happy to go back to my corner and sit quietly :)

> So realistically, I think the DOI + opaque label is useful between very
> compatible systems.

Of course.  I agree there are a lot of things you can do with a DOI + opaque 
label, especially if you are only concerned about end-to-end security issues 
which I believe is the case for labeled NFS.

> Given that limitation, may be the "package" is small enough and can be
> passed in RPC layer during authentication so that MLS can share files with
> like MLS systems, and same is true for DTE, fmac, smack, ....

Well, I think all that the opaque label buys you is the ability to limit who 
you share the security policy/translation "package" with, as those systems 
that participate in the labeled communication (be it NFS, generic IP or some 
other random service) still need to worry about label translation and security 
policy differences if they want to enforce policy locally.

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Tue, Mar 31, 2009 at 08:33:07PM -0700, Jarrett Lu wrote:
> Nicolas Williams wrote:
> >On Mon, Mar 30, 2009 at 10:59:15PM -0700, Jarrett Lu wrote:
> >  
> >>That's certainly one option. We can say DOI + an opaque field is what we 
> >>will add to NFSv4 protocol. Use the information as you see fit. Going 
> >>    
> >
> >That's what David's I-D and what my RPCSEC_GSSv3 I-D both say now.
> >  
> 
> If we stop here, we don't have much of an interoperability story. I 

I don't agree.  We'd have the same interop story everyone has today
w.r.t. labeling: synchronization of policies is an out-of-band, manual
(automatable) task; no standard protocol nor policy description
language is specified.

Note: I'm not saying that I don't want us to do better.  Rather, I'm
saying that we should consider whether to: a) proceed as now, b) also
separately and independently solve the policy agreement issues, c) make
the labeled NFSv4 work dependent on a solution to the policy agreement
issues.

I'm in favor of (a) and (b), but if we can reach consensus on a sketch
of a policy agreement solution, then I'd be willing to go for (c).

I.e., we should be realistic about what we can accomplish.

> >Signature of security policy is certainly an interesting idea!  But it
> >does require defining a standard security policy description syntax --
> >that's work that I think is well outside what this WG should be working
> >on.  (Also, we'll need hash function agility.)
> >
> >Therefore I think the NFSv4 community should stop at either
> >
> 
> I'm in general agreement with you on this. I am not sure to what extent 
> the extensibility stuff makes sense, e.g. how much may be enough? I 
> guess we need to study more use scenarios. I suspect TE systems may have 
> more challenges in this area, just because security policies on TE 
> systems tend to be more flexible. For example, how many things are 
> critical in order to translate label correctly, OS version, vendor, 
> label parser, security policy file? How likely DTE systems are 
> configured with exact same policy files? Does it make sense that a 
> (harmless) update to security policy file causes label translation 
> failures from that point on?

I've re-thought this a bit.  I think we need the policy agreement parts
to be:

 - provided by authentication mechanisms where possible (PKIX cert
   extensions, Kerberos V authz-data, SAML assertions, ...)

 - exchanged by the client and server via a new operation

The label should remain {DOI #, octet string}.  Clients and servers that
can reach policy agreement via out-of-band mechanisms will need no
authentication mechanism extensions, nor any NFSv4 policy agreement
operations.  Other clients and servers would use whatever policy
agreement mechanism is available to them, preferably authentication
mechanism extensions.

Policy agreement should consist of a sequence of {DOI #, policy encoding
type, hash function algorithm, hash of policy}.  If a client and server
have one common policy for one or more DOIs then they can use those
DOIs.  For all DOIs they don't agree on they'd fail to move bits (or
whatever is the preferred outcome).

> >[comments about where to do what work elided]
> 
> No disagreement here either. At the end of this scoping exercise, we'll 
> hopefully know how big a bite we can chew. I believe the DOI + opaque 
> field may be useful to identical or compatible system under same 
> administrative control. To push David's draft forward, I believe we 
> still need to understand more about how different systems may use the 
> opaque field and decide if it makes sense to propose extensibility 
> fields for future use.

Agreed.

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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Wed, Apr 01, 2009 at 12:46:33PM -0400, Paul Moore wrote:
> My only comment was that figuring out how to transfer information over the 
> network isn't really that important yet.  Reading through the thread I don't 
> think there is general agreement on what we even need to send to enable proper 
> label translation/encoding/etc.

I think we all agree that a client and server have to agree on the
meaning of any given DOI number so that they can properly encode labels.

In order to interop this means we need a common label encoding for any
given DOI.

I think we agree on that, no?

That leaves this problem: how to ensure that the client and server do
actually agree as to a given DOI's label encodings?

That's a big problem that to date has been solved by out-of-band
mechanisms.  That solution leaves interoperability in a lurch: it's up
to vendors to cooperate to obtain a common security policy for use on
the wire.

I think Jarret's quite right to ask that we do better than that.

Doing better means: a) coming up with a common labeled security policy
language for MLS and DTE, b) ensuring that clients and servers agree on
a DOI's policy.

(a) is hard because we'd have to harmonize the differences between
exiting operating systems' labeled security policies, but I doubt it's
infeasible.  (b) is easy: exchange name+version of a DOI's security
policy and you're done (this can be a URL, a hash of the policy
document, whatever).

> > True. The first question is whether we should try to solve, or at least
> > ease, the label interpretation / translation problem in the context of
> > NFSv4 protocol. I don't know if we can solve it, but it seems worthwhile
> > to explore further, to gain more understanding if nothing else.
> 
> I've been trying to look at this problem in a more generic sense and not just 
> from a labeled NFS point of view.  While the current pain point is labeled NFS 
> the idea of label translation/encoding/etc is not exclusive to NFS or network 
> filesystems in general; I'm sure we can all agree on this.  While we may need 
> to solve (as best we can) the label translation issues on a per-application 
> basis I really hope that we might be able to develop a solution which can be 
> used across multiple applications and not just NFS.

+1

> > The challenge of interpreting and translating labels is that one system
> > needs to know a lot of info about its peer. And there is no good way to
> > describe the (sometimes subtle) difference. I think this problem may be
> > harder on DTE systems than on MLS systems, I believe.
> 
> I'm not sure we will ever be able to arrive at a solution that requires a 
> system to be able to understand the security policy/labels of another; things 
> change to much and I don't think anyone's crystal ball is that good.  
> Personally I think the best we can do is hope for a solution that allows a 
> system to understand a security policy/label system defined by a pre-existing 
> DOI definition.  If we can do that then we can at least allow two different 
> systems to communicate via an agreed upon DOI regardless of their internal 
> security policies/labels.  I'll admit it isn't perfect, but I think the 
> problem space is much smaller and likely to have less churn over time.

+1

> > Assuming we can assemble all the information required to do
> > label translation correctly into a package, passing that around the
> > systems seem inefficient, non-scalable ...

There's no need to refer to labeled security policies by value at the
application protocol layer -- just by name/reference.  The common policy
can be referenced by URL so that it can be downloaded only when it's
changed.

> > ... and probably outside the scope of labeled NFSv4 enhancement.
> 
> Perhaps.  Keep in mind I'm trying to think a bit more generically; if that 
> isn't the goal I'll be happy to go back to my corner and sit quietly :)

Parts of the solution will be outside the scope of the NFSv4 WG.  That
doesn't mean we can't undertake a solution.  Assuming (a) (see above) we
need only specify (b) (see above) for NFSv4 -- we can leave (a) to
another WG.

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.

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Paul Moore]

On Thursday 02 April 2009 11:24:24 am Nicolas Williams wrote:
> On Wed, Apr 01, 2009 at 12:46:33PM -0400, Paul Moore wrote:
> > My only comment was that figuring out how to transfer information over
> > the network isn't really that important yet.  Reading through the thread
> > I don't think there is general agreement on what we even need to send to
> > enable proper label translation/encoding/etc.
>
> I think we all agree that a client and server have to agree on the
> meaning of any given DOI number so that they can properly encode labels.
>
> In order to interop this means we need a common label encoding for any
> given DOI.
>
> I think we agree on that, no?

Yep.  Although I don't think we should try to force a single label encoding 
for all DOIs (couldn't tell from your reply how far you wanted to take this); 
using some combination of DOI+<opaque label> seems reasonable.

> That leaves this problem: how to ensure that the client and server do
> actually agree as to a given DOI's label encodings?
>
> That's a big problem that to date has been solved by out-of-band
> mechanisms.  That solution leaves interoperability in a lurch: it's up
> to vendors to cooperate to obtain a common security policy for use on
> the wire.

Well, I think the trick is you define a security policy and label format in 
the DOI and then leave it up to the various implementations to handle the 
necessary internalization and import/export of the DOI.  Perhaps we are in a 
six-of-one/half-dozen-of-the-other discussion right now.

> I think Jarret's quite right to ask that we do better than that.

I'm not arguing that we try to do better than has been done before, I'm a big 
fan of "better".  My only concern is that if we do "better" we do "better" for 
more than just NFS.

> Doing better means: a) coming up with a common labeled security policy
> language for MLS and DTE

At this point I'm glad there is an option "B" :)

> b) ensuring that clients and servers agree on a DOI's policy.

As you point out, this seems much more reasonable of a goal.

> > > ... and probably outside the scope of labeled NFSv4 enhancement.
> >
> > Perhaps.  Keep in mind I'm trying to think a bit more generically; if
> > that isn't the goal I'll be happy to go back to my corner and sit quietly
> > :)
>
> Parts of the solution will be outside the scope of the NFSv4 WG.  That
> doesn't mean we can't undertake a solution.  Assuming (a) (see above) we
> need only specify (b) (see above) for NFSv4 -- we can leave (a) to
> another WG.

I guess I personally don't really care about WG boundaries right now, I'm 
mostly interested in arriving at a decent, complete solution.  My belief is 
that once we arrive at a good idea we can divide it up amongst whatever WGs 
are appropriate.

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On 04/01/09 10:50, Nicolas Williams wrote:
> On Tue, Mar 31, 2009 at 08:33:07PM -0700, Jarrett Lu wrote:
>   
>> Nicolas Williams wrote:
>>     
>>> On Mon, Mar 30, 2009 at 10:59:15PM -0700, Jarrett Lu wrote:
>>>  
>>>       
>>>> That's certainly one option. We can say DOI + an opaque field is what we 
>>>> will add to NFSv4 protocol. Use the information as you see fit. Going 
>>>>    
>>>>         
>>> That's what David's I-D and what my RPCSEC_GSSv3 I-D both say now.
>>>  
>>>       
>> If we stop here, we don't have much of an interoperability story. I 
>>     
>
> I don't agree.  We'd have the same interop story everyone has today
> w.r.t. labeling: synchronization of policies is an out-of-band, manual
> (automatable) task; no standard protocol nor policy description
> language is specified.
>   

I don't mean to dwell on this. Requiring either systems being identical 
or relying on OOB information to know whether the opaque field can be 
used sounds weak on interoperability.  ;-)

I agree with you on rest of your comments. I still think more detailed 
study on different use cases are needed to understand whether the 
proposed solutions are suitable, sufficient, etc..

Jarrett


[-- Attachment #2: Type: text/html, Size: 1769 bytes --]

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Jarrett Lu]

[-- Attachment #1: Type: text/plain, Size: 5589 bytes --]

On 04/01/09 09:46, Paul Moore wrote:
> On Wednesday 01 April 2009 03:46:58 am Jarrett Lu wrote:
>   
>
[ ... ]
>
>   
>> The challenge of interpreting and translating labels is that one system
>> needs to know a lot of info about its peer. And there is no good way to
>> describe the (sometimes subtle) difference. I think this problem may be
>> harder on DTE systems than on MLS systems, I believe.
>>     
>
> I'm not sure we will ever be able to arrive at a solution that requires a 
> system to be able to understand the security policy/labels of another; things 
> change to much and I don't think anyone's crystal ball is that good.  
> Personally I think the best we can do is hope for a solution that allows a 
> system to understand a security policy/label system defined by a pre-existing 
> DOI definition.  If we can do that then we can at least allow two different 
> systems to communicate via an agreed upon DOI regardless of their internal 
> security policies/labels.  I'll admit it isn't perfect, but I think the 
> problem space is much smaller and likely to have less churn over time.
>   

This comes back to semantics of DOI. So far, I heard two slightly 
different versions:
(1) DOI is a key to a set of label parsing functions. Knowing the DOI 
value implies the parser on the system knows how to parse the octet 
string in opaque field. It says nothing about whether a peer's label can 
be correctly interpreted. I believe Daivd's draft uses this definition. 
(2) In addition to being able to parse the opaque field, DOI also 
implies communicating systems have consistent label policy and encoding. 
Systems with inconsistent policies are not supposed to use same DOI. 
This definition is closer to the CALIPSO DOI, and is how MLS systems use 
DOI today.

While (1) is easier to specify on the wire, I am not clear on what it 
takes to use it safely even when OOB methods are used. Since this 
definition doesn't say who should use this DOI and who is not supposed 
to, what happens when a node, which has not consented to the agreement 
over the OOB method, uses the same DOI and octet string format but with 
inconsistent label policy? (2) has an easier usage model, IMO. But it's 
harder to define a "pre-existing" DOI., e.g.  define DOI X to mean 
vendor ABC, OS version 1.0, label policy 2.0, label parser version 3.0, 
etc., and store that in some kind of registry. I think Nico's "URL 
during authentication" idea is interesting.

>>> Ultimately I believe that the required label translation information
>>> (wire/DOI label to internal and the other way around) is going to need to
>>> be bundled with the system's security policy and distributed as a single
>>> "package". Granted this does require prior knowledge of the DOIs in use
>>> but I believe this is a much easier requirement than the opposite.  From
>>> a practical point of view this isn't too far removed from the notion of
>>> sending sending label encoding data upon joining the network, the big
>>> difference is that we are sending both security policy and label
>>> encoding/DOI-translation data at the same time (in the TSOL case I
>>> suspect this would just be the label encoding data, which may mean the
>>> original poster had this in mind).
>>>       
>> Depending how different the systems are, the "package" content will be
>> different.
>>     
>
> Yep, that is the point; squares hole need square pegs, round holes need round 
> pegs.
>
>   
>> Assuming we can assemble all the information required to do
>> label translation correctly into a package, passing that around the
>> systems seem inefficient, non-scalable ...
>>     
>
> Honestly I don't see it as being that far removed from many of the current 
> solutions that ship "security policy" to individual systems through the 
> network/enterprise.  Also look at some of the NAC stuff that is being used 
> these days, how is a security policy/translation "package" all that different 
> from an anti-virus update or a set of os/application patches?
>
> It is a solvable problem, or at least one that users have shown a willingness 
> to tolerate.
>   

I was thinking how to do that within a protocol enhancement.

>   
>> ... and probably outside the scope of labeled NFSv4 enhancement.
>>     
>
> Perhaps.  Keep in mind I'm trying to think a bit more generically; if that 
> isn't the goal I'll be happy to go back to my corner and sit quietly :)
>
>   
>> So realistically, I think the DOI + opaque label is useful between very
>> compatible systems.
>>     
>
> Of course.  I agree there are a lot of things you can do with a DOI + opaque 
> label, especially if you are only concerned about end-to-end security issues 
> which I believe is the case for labeled NFS.
>
>   
>> Given that limitation, may be the "package" is small enough and can be
>> passed in RPC layer during authentication so that MLS can share files with
>> like MLS systems, and same is true for DTE, fmac, smack, ....
>>     
>
> Well, I think all that the opaque label buys you is the ability to limit who 
> you share the security policy/translation "package" with, as those systems 
> that participate in the labeled communication (be it NFS, generic IP or some 
> other random service) still need to worry about label translation and security 
> policy differences if they want to enforce policy locally.
>   

I am still trying to understand what is needed to make safe sharing 
possible. BTW, are you implying that it's always necessary to do one 
label translation, e.g. from on-the-wire format to a native label format?


Jarrett



[-- Attachment #2: Type: text/html, Size: 6712 bytes --]

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams]

On Thu, Apr 02, 2009 at 06:35:50PM -0400, Paul Moore wrote:
> On Thursday 02 April 2009 11:24:24 am Nicolas Williams wrote:
> > On Wed, Apr 01, 2009 at 12:46:33PM -0400, Paul Moore wrote:
> > > My only comment was that figuring out how to transfer information over
> > > the network isn't really that important yet.  Reading through the thread
> > > I don't think there is general agreement on what we even need to send to
> > > enable proper label translation/encoding/etc.
> >
> > I think we all agree that a client and server have to agree on the
> > meaning of any given DOI number so that they can properly encode labels.
> >
> > In order to interop this means we need a common label encoding for any
> > given DOI.
> >
> > I think we agree on that, no?
> 
> Yep.  Although I don't think we should try to force a single label encoding 
> for all DOIs (couldn't tell from your reply how far you wanted to take this); 
> using some combination of DOI+<opaque label> seems reasonable.

Right.  Once again we have a disconnect on what is meant by "label
encoding" -- only this time I'd adopted Jarret's use of the term for
what Solaris TX calls label encodings and confused you (Jarret had
confused me earlier).

> > That leaves this problem: how to ensure that the client and server do
> > actually agree as to a given DOI's label encodings?
> >
> > That's a big problem that to date has been solved by out-of-band
> > mechanisms.  That solution leaves interoperability in a lurch: it's up
> > to vendors to cooperate to obtain a common security policy for use on
> > the wire.
> 
> Well, I think the trick is you define a security policy and label format in 
> the DOI and then leave it up to the various implementations to handle the 
> necessary internalization and import/export of the DOI.  Perhaps we are in a 
> six-of-one/half-dozen-of-the-other discussion right now.

What Jarret means by label encoding is "the mappings of human readable
labels to bits on the wire" not just "the generic mapping of internal
MLS labels to bits on the wire" (which CALIPSO does provide, for
example).

> > Doing better means: a) coming up with a common labeled security policy
> > language for MLS and DTE
> 
> At this point I'm glad there is an option "B" :)

These aren't options -- these two go together.

> > b) ensuring that clients and servers agree on a DOI's policy.
> 
> As you point out, this seems much more reasonable of a goal.

For how else do you get a heterogeneous network to agree on a DOI's
policy if not by having a generic way to represent that policy?  The
alternative is to show that two descriptions of the same policy but in
different languages are equivalent, and that strikes me as mostly
equivalent to having a common language -- but a common language would
surely be easier to work with.

> > Parts of the solution will be outside the scope of the NFSv4 WG.  That
> > doesn't mean we can't undertake a solution.  Assuming (a) (see above) we
> > need only specify (b) (see above) for NFSv4 -- we can leave (a) to
> > another WG.
> 
> I guess I personally don't really care about WG boundaries right now, I'm 
> mostly interested in arriving at a decent, complete solution.  My belief is 
> that once we arrive at a good idea we can divide it up amongst whatever WGs 
> are appropriate.

Sure.

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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Joy Latten]

On Thu, 2009-04-02 at 18:35 -0400, Paul Moore wrote:
> On Thursday 02 April 2009 11:24:24 am Nicolas Williams wrote:
> > On Wed, Apr 01, 2009 at 12:46:33PM -0400, Paul Moore wrote:
> > > My only comment was that figuring out how to transfer information over
> > > the network isn't really that important yet.  Reading through the thread
> > > I don't think there is general agreement on what we even need to send to
> > > enable proper label translation/encoding/etc.
> >
> > I think we all agree that a client and server have to agree on the
> > meaning of any given DOI number so that they can properly encode labels.
> >
> > In order to interop this means we need a common label encoding for any
> > given DOI.
> >
> > I think we agree on that, no?
> 
> Yep.  Although I don't think we should try to force a single label encoding 
> for all DOIs (couldn't tell from your reply how far you wanted to take this); 
> using some combination of DOI+<opaque label> seems reasonable.
> 
> > That leaves this problem: how to ensure that the client and server do
> > actually agree as to a given DOI's label encodings?
> >
> > That's a big problem that to date has been solved by out-of-band
> > mechanisms.  That solution leaves interoperability in a lurch: it's up
> > to vendors to cooperate to obtain a common security policy for use on
> > the wire.
> 
> Well, I think the trick is you define a security policy and label format in 
> the DOI and then leave it up to the various implementations to handle the 
> necessary internalization and import/export of the DOI.  Perhaps we are in a 
> six-of-one/half-dozen-of-the-other discussion right now.

I am just getting to read this thread. I find it interesting because the
labeled ipsec draft expresses DOI + opaque string in similar manner as
the labeled nfsv4 draft. 

Upon reading the thread, I agree with you, define a security policy and 
label format in the DOI and leave it up to implementation to handle
internalization.

I had always assumed the DOI would be handled by IANA and when a request
was made for a new DOI number, a definition would be included. 
For example, DOI #5: mapping between MAC implementation A version xx,
label policy B AND MAC implementation G version xx, label policy R.
Or maybe something like, DOI #6: SElinux version XX, using MCS.

The sys admin would determine based on local MAC, mappings, etc...,
which DOI to use/communicate. 

This perhaps sounds somewhat primitive, but I am still processing all
the info communicated in the thread. :-)

regards,
Joy 


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

Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Paul Moore]

On Thursday 02 April 2009 09:21:08 pm Jarrett Lu wrote:
> On 04/01/09 09:46, Paul Moore wrote:
> > On Wednesday 01 April 2009 03:46:58 am Jarrett Lu wrote:
> >> ... and probably outside the scope of labeled NFSv4 enhancement.
> >
> > Perhaps.  Keep in mind I'm trying to think a bit more generically; if
> > that isn't the goal I'll be happy to go back to my corner and sit quietly
> > :)
> >
> >> So realistically, I think the DOI + opaque label is useful between very
> >> compatible systems.
> >
> > Of course.  I agree there are a lot of things you can do with a DOI +
> > opaque label, especially if you are only concerned about end-to-end
> > security issues which I believe is the case for labeled NFS.
> >
> >> Given that limitation, may be the "package" is small enough and can be
> >> passed in RPC layer during authentication so that MLS can share files
> >> with like MLS systems, and same is true for DTE, fmac, smack, ....
> >
> > Well, I think all that the opaque label buys you is the ability to limit
> > who you share the security policy/translation "package" with, as those
> > systems that participate in the labeled communication (be it NFS, generic
> > IP or some other random service) still need to worry about label
> > translation and security policy differences if they want to enforce
> > policy locally.
>
> I am still trying to understand what is needed to make safe sharing
> possible. BTW, are you implying that it's always necessary to do one
> label translation, e.g. from on-the-wire format to a native label format?

[Sorry for the delayed response.]

As I said earlier I think the easiest way forward is to design systems that 
can interoperate with established DOI definitions and not worry about what 
other peer systems are using for a security mechanism.  In some cases that 
will require translations from a native label format to a wire format and back 
to a label format; in some cases it may result in no translations at all.  It 
all depends on the individual systems and the DOI.

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