my thoughts on how Labeled NFSv4 draft should move forward

my thoughts on how Labeled NFSv4 draft should move forward

[Jarrett Lu]

David,

There were a lot of discussion on labeled NFSv4 recently. I like to make 
a suggestion in how your draft should go forward.  I believe you should 
continue proposing adding a DOI + an opaque label field. There are two 
slightly different usage models of DOI:
(1) the current proposal -- DOI is used to indicate the format of label 
in the opaque field. A new predefined DOI / label format pairing needs 
to exist in a registry. Being able to parse a label doesn't necessarily 
imply one can correctly interpret or translate a label. Label policy 
consistency is administered outside of the Labeled NFSv4 protocol 
extension. (2) Using same DOI implies that communicating peers can 
correctly parse the opaque label field AND label policy between 
communicating parties are consistent, i.e. they can correctly interpret 
labels using same DOI.  This DOI usage is consistent with CALIPSO DOI; 
hence the same DOI registry can be used by NFSv4. I like (2) better for 
following reasons:

- It removes the need for another DOI registry. I believe a new DOI 
registry will be under scrutiny and may cause uneasiness in IETF later on.

- It is consistent with how MAC systems use DOI today. Granted that the 
CALIPSO spec is MLS centric. But DOI need not favor MLS systems in any 
way. It could be effectively used on DTE systems as well. For example, 
DOI number 5 means a pair of DTE system sharing consistent label 
security policies.

- I believe it's easier to implement MAC policy consistency on a system 
where DOI conveys the same meaning in different layer of a system stack.

In any case, the "DOI  + opaque label" proposal relies on an OOB method 
to be useful. This is weak in terms of interoperability. But I believe 
that allowing systems to share file label attribute still adds value, 
even when an OOB method is required. I can help writing some usage 
scenarios about how such extensions may be used on MLS systems.

Now there is a separate discussion on saag list in how to do policy 
exchange among MAC systems. If this can be done, labeled NFS can 
definitely benefit from that effort and improve its interoperability 
story. It's probably wise to separate the two efforts so that each can 
proceed independently. I haven't studied the "labeled policy exchange 
framework" enough to know if it changes the current NFSv4 proposal.


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] my thoughts on how Labeled NFSv4 draft should move forward

[Nicolas Williams]

On Mon, Apr 06, 2009 at 02:07:04PM -0700, Jarrett Lu wrote:
> There were a lot of discussion on labeled NFSv4 recently. I like to make 
> a suggestion in how your draft should go forward.  I believe you should 
> continue proposing adding a DOI + an opaque label field. There are two 
> slightly different usage models of DOI:
> (1) the current proposal -- DOI is used to indicate the format of label 
> in the opaque field. A new predefined DOI / label format pairing needs 
> to exist in a registry. Being able to parse a label doesn't necessarily 
> imply one can correctly interpret or translate a label. Label policy 
> consistency is administered outside of the Labeled NFSv4 protocol 
> extension. (2) Using same DOI implies that communicating peers can 
> correctly parse the opaque label field AND label policy between 
> communicating parties are consistent, i.e. they can correctly interpret 
> labels using same DOI.  This DOI usage is consistent with CALIPSO DOI; 
> hence the same DOI registry can be used by NFSv4. I like (2) better for 
> following reasons:

The difference between (1) and (2) is artificial since in both cases the
client and the server have to agree on what each DOI they use means.
The difference is only whether we ought to have a registry.  Clearly we
should not, for all the reasons that you list in part because we may well want to go with DOI+opaque now
and later add support for agreeing on security policy subsets (by, e.g.,
exchanging URIs of policies specified in SPIF or whatever), so defining
a registry would be a waste of effort later.

Option 3: send DOI+label_format+opaque_label.  But still, this strikes
me as unnecessary -- the client and server have to agree on what the DOI
means, so they might as well agree on what the label format is (MLS,
DTE, ...).

> In any case, the "DOI  + opaque label" proposal relies on an OOB method 
> to be useful. This is weak in terms of interoperability. But I believe 
> that allowing systems to share file label attribute still adds value, 
> even when an OOB method is required. I can help writing some usage 
> scenarios about how such extensions may be used on MLS systems.

Yes, but you've convinced me that we need to solve that interoperability
problem.  I don't think we should block labeled NFSv4 on solving that
problem, but we should have an idea of how we'll shoehorn a solution
into labeled NFSv4 later.  Fortunately labeled NFSv4 will rely on
RPCSEC_GSSv3, which I've designed to be extensible from the get-go.

> Now there is a separate discussion on saag list in how to do policy 
> exchange among MAC systems. If this can be done, labeled NFS can 
> definitely benefit from that effort and improve its interoperability 
> story. It's probably wise to separate the two efforts so that each can 
> proceed independently. I haven't studied the "labeled policy exchange 
> framework" enough to know if it changes the current NFSv4 proposal.

I agree.

--
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] my thoughts on how Labeled NFSv4 draft should move forward

[David P. Quigley]

So we agree that in abstract there is no difference between 1 and 2
however fundamentally we believe that the label format belongs in a
registry that people can consult, for the reasons that I specified in my
reply to Jarrett, while the label semantics really belong to the
specific authorities that determine them. By separating the two we
separate the hard problem (policy reconciliation) from the label
transport problem within the respective applications.

We see something similar to your option three as being the correct
solution. Instead of DOI+label_format+opaque_label we see the DOI as
being the label format specifier and then within the opaque label we
have an authority field which will allow you to determine the label
semantics. An example of its use would be for CALIPSO to request a DOI
for their label format and then within the opaque section use their DOI
to identify the label semantics.

With respect to the URIs we have a few issues with using them as a way
of specifying policy. First off they are spoofable as we can't
definitively guarantee the integrity of the URI and its source. A
related question is can we actually define the policy documents it would
point to in the face of the variability required by today's systems? The
specifications in the past worked to some extent due to the static
nature of the policy which isn't something we can assume with today's
systems. Also taking this into account how do we then proceed to
automate this process?

Dave

On Mon, 2009-04-06 at 17:08 -0500, Nicolas Williams wrote:
> On Mon, Apr 06, 2009 at 02:07:04PM -0700, Jarrett Lu wrote:
> > There were a lot of discussion on labeled NFSv4 recently. I like to make 
> > a suggestion in how your draft should go forward.  I believe you should 
> > continue proposing adding a DOI + an opaque label field. There are two 
> > slightly different usage models of DOI:
> > (1) the current proposal -- DOI is used to indicate the format of label 
> > in the opaque field. A new predefined DOI / label format pairing needs 
> > to exist in a registry. Being able to parse a label doesn't necessarily 
> > imply one can correctly interpret or translate a label. Label policy 
> > consistency is administered outside of the Labeled NFSv4 protocol 
> > extension. (2) Using same DOI implies that communicating peers can 
> > correctly parse the opaque label field AND label policy between 
> > communicating parties are consistent, i.e. they can correctly interpret 
> > labels using same DOI.  This DOI usage is consistent with CALIPSO DOI; 
> > hence the same DOI registry can be used by NFSv4. I like (2) better for 
> > following reasons:
> 
> The difference between (1) and (2) is artificial since in both cases the
> client and the server have to agree on what each DOI they use means.
> The difference is only whether we ought to have a registry.  Clearly we
> should not, for all the reasons that you list in part because we may well want to go with DOI+opaque now
> and later add support for agreeing on security policy subsets (by, e.g.,
> exchanging URIs of policies specified in SPIF or whatever), so defining
> a registry would be a waste of effort later.
> 
> Option 3: send DOI+label_format+opaque_label.  But still, this strikes
> me as unnecessary -- the client and server have to agree on what the DOI
> means, so they might as well agree on what the label format is (MLS,
> DTE, ...).
> 
> > In any case, the "DOI  + opaque label" proposal relies on an OOB method 
> > to be useful. This is weak in terms of interoperability. But I believe 
> > that allowing systems to share file label attribute still adds value, 
> > even when an OOB method is required. I can help writing some usage 
> > scenarios about how such extensions may be used on MLS systems.
> 
> Yes, but you've convinced me that we need to solve that interoperability
> problem.  I don't think we should block labeled NFSv4 on solving that
> problem, but we should have an idea of how we'll shoehorn a solution
> into labeled NFSv4 later.  Fortunately labeled NFSv4 will rely on
> RPCSEC_GSSv3, which I've designed to be extensible from the get-go.
> 
> > Now there is a separate discussion on saag list in how to do policy 
> > exchange among MAC systems. If this can be done, labeled NFS can 
> > definitely benefit from that effort and improve its interoperability 
> > story. It's probably wise to separate the two efforts so that each can 
> > proceed independently. I haven't studied the "labeled policy exchange 
> > framework" enough to know if it changes the current NFSv4 proposal.
> 
> I agree.


--
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: my thoughts on how Labeled NFSv4 draft should move forward

[David P. Quigley]

Hello,
   Pete, Steve, and I have taken in the results of the last week and a
half of discussion and have discussed the way we see things working. We
believe that the DOI usage model that you have marked as number 1 is the
one we would like to see agreed on eventually. There are several reasons
we it the first being that it allows for a much smaller DOI space than
would normally be required. By only specifying the format of the label
in the DOI it allows for implementers to easily develop systems to parse
these labels. This method also allows for a more dynamic policy at the
end points allowing for customizations to be made on a site specific
basis without having to use an external entity such as IANA. This
doesn't mean that there will be no authority to provide semantic
information on policies but rather that authority is not specified in
the DOI field. The cool part of using this method is that we can have
DOI 5 be CALIPSO formatted labels and in the opaque field we can use the
complete CALIPSO label specification DOI and all. In this case the
CALIPSO DOI would be an authority identifier to allow the system to
obtain the necessary information. 

To address your first point below we believe that if the DOI space is
sufficiently small and we can define a reasonable way to specify the
label format for parsing purposes that the IETF won't mind that we have
this registry. The question here is how finely do we define the label
specification for a DOI. For example, the SELinux context can be
described as, 1) a string, 2) a colon separated string, 3) a colon
separated string where the first component is a user, the second
component is a role, the third component is a type, and there is an
optional 4th component of an MLS range. We can even go further and say
do we want to specify in some form of regex the valid forms of each
component. I think if the registry contains information like that it
will be very valuable to implementers and will be accepted.

To address your second point, most MAC systems in deployment today are
in fact MLS centric and as Casey has pointed out the problem space has
grown to be larger than just MLS. Because the methods and documents that
people have been discussing over the last couple of weeks are so
engrained with MLS we don't believe that they will generalize well to
other MAC systems such as Type Enforcement. The reason these older
methods were able to work is because the policy was statically defined.
Modern systems require the ability to provide additional policy
configuration on the end points and this dynamic nature makes it seem
unlikely that the older methods will generalize to be able to
accommodate this.

Finally to address your third point we think that it is wrong to assume
that there should be the same DOI across all levels in a system. This
assumption is very limiting to the system design because it assumes that
all levels will be concerned with all information. For example a system
may be using CALIPSO to label its network traffic but once that traffic
comes into the endpoint or is received by the other endpoint it may
translate it into a preferred internal label representation that is
completely different.

Dave

On Mon, 2009-04-06 at 14:07 -0700, Jarrett Lu wrote: 
> David,
> 
> There were a lot of discussion on labeled NFSv4 recently. I like to make 
> a suggestion in how your draft should go forward.  I believe you should 
> continue proposing adding a DOI + an opaque label field. There are two 
> slightly different usage models of DOI:
> (1) the current proposal -- DOI is used to indicate the format of label 
> in the opaque field. A new predefined DOI / label format pairing needs 
> to exist in a registry. Being able to parse a label doesn't necessarily 
> imply one can correctly interpret or translate a label. Label policy 
> consistency is administered outside of the Labeled NFSv4 protocol 
> extension. (2) Using same DOI implies that communicating peers can 
> correctly parse the opaque label field AND label policy between 
> communicating parties are consistent, i.e. they can correctly interpret 
> labels using same DOI.  This DOI usage is consistent with CALIPSO DOI; 
> hence the same DOI registry can be used by NFSv4. I like (2) better for 
> following reasons:
> 
> - It removes the need for another DOI registry. I believe a new DOI 
> registry will be under scrutiny and may cause uneasiness in IETF later on.
> 
> - It is consistent with how MAC systems use DOI today. Granted that the 
> CALIPSO spec is MLS centric. But DOI need not favor MLS systems in any 
> way. It could be effectively used on DTE systems as well. For example, 
> DOI number 5 means a pair of DTE system sharing consistent label 
> security policies.
> 
> - I believe it's easier to implement MAC policy consistency on a system 
> where DOI conveys the same meaning in different layer of a system stack.
> 
> In any case, the "DOI  + opaque label" proposal relies on an OOB method 
> to be useful. This is weak in terms of interoperability. But I believe 
> that allowing systems to share file label attribute still adds value, 
> even when an OOB method is required. I can help writing some usage 
> scenarios about how such extensions may be used on MLS systems.
> 
> Now there is a separate discussion on saag list in how to do policy 
> exchange among MAC systems. If this can be done, labeled NFS can 
> definitely benefit from that effort and improve its interoperability 
> story. It's probably wise to separate the two efforts so that each can 
> proceed independently. I haven't studied the "labeled policy exchange 
> framework" enough to know if it changes the current NFSv4 proposal.
> 
> 
> 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] my thoughts on how Labeled NFSv4 draft should move forward

[Nicolas Williams]

After that long thread on SAAG and a subsequent off-list discussion with
Casey (plus my reading Smack documentation) I'm almost ready to reach
the following conclusions:

 - We don't need policy agreement for MLS.  Servers have all the
   necessary information when comparing labels without reference to a
   policy.  However, clients have to be sharing a common MLS policy.

 - For "smart" MLS and Smack servers we need a method by which servers
   can determine the label range/set of client and user principals, but
   this need not be specified in a standard way except where label
   range/set is borne by authentication credentials (Kerberos V ticket
   authorization-data, PKIX cert extensions).

   This is already described in my RPCSEC_GSSv3 document.

 - For Smack we don't need policy agreement either, but it will be
   useful to distribute common subsets of Smack policy to clients, and
   to prefix labels from local-only sub-policies with a client ID (or
   client DOI, if you wish).

 - For DTE I've no idea what to do.  Policy agreement seems like a
   flight of fancy for DTE.  But *much* more importantly, because the
   process label transitions can span so many labels we simply cannot
   have too smart a server: the server can't meaningfully constrain the
   labels that a user@client can assert, therefore the server must trust
   all client assertions of process DTE labels or none at all.

   I.e., for DTE we can only have "dumb" servers.

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] my thoughts on how Labeled NFSv4 draft should move forward

[Nicolas Williams]

On Fri, Apr 10, 2009 at 03:17:18PM -0500, Nicolas Williams wrote:
> After that long thread on SAAG and a subsequent off-list discussion with
> Casey (plus my reading Smack documentation) I'm almost ready to reach
> the following conclusions:

I should expand on this.  See below.

>  - We don't need policy agreement for MLS.  Servers have all the
>    necessary information when comparing labels without reference to a
>    policy.  However, clients have to be sharing a common MLS policy.

Which means DOI + label in CALIPSO-like label representation is
sufficient.  DOI + opaque label is also good enough for MLS if the DOI
can be used to find the label representation.

>  - For "smart" MLS and Smack servers we need a method by which servers
>    can determine the label range/set of client and user principals, but
>    this need not be specified in a standard way except where label
>    range/set is borne by authentication credentials (Kerberos V ticket
>    authorization-data, PKIX cert extensions).
> 
>    This is already described in my RPCSEC_GSSv3 document.

Which means we can proceed with this RPCSEC_GSSv3 aspect of labeled NFS.

Of course, it's not clear yet that it will be of much practical value to
have such smart servers (e.g., if all the clients would be fully trusted
anyways).  It may be possible that "dumb" servers are good enough, in
which case we don't need to complicate RPCSEC_GSSv3 with process label
assertions (though it's not much of a complication, but the client does
need to know, via an NFS operation, whether the server is smart or
dumb).

>  - For Smack we don't need policy agreement either, but it will be
>    useful to distribute common subsets of Smack policy to clients, and
>    to prefix labels from local-only sub-policies with a client ID (or
>    client DOI, if you wish).

Which means we may want to have DOI + opaque label, and, perhaps, DOI +
client ID + opaque label (but a client ID can be in the opaque label).

It should be noted that Smack does have a way to encode Smack labels as
CIPSO MLS labels, though it is a hack.  We could similarly represent
Smack labels via whatever MLS label representation we use -- but it'd be
better (i.e., not hacky) to just have opaque labels for Smack.

>  - For DTE I've no idea what to do.  Policy agreement seems like a
>    flight of fancy for DTE.  But *much* more importantly, because the
>    process label transitions can span so many labels we simply cannot
>    have too smart a server: the server can't meaningfully constrain the
>    labels that a user@client can assert, therefore the server must trust
>    all client assertions of process DTE labels or none at all.
> 
>    I.e., for DTE we can only have "dumb" servers.

Which means that for DTE we should have DOI + opaque label and all the
server does is store them.  The server would not enfore DTE policies:
only clients would.  Of course, the server can have share-level ACLs to
decide which clients are trusted, but the server remains dumb.

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] my thoughts on how Labeled NFSv4 draft should move forward

[David P. Quigley]

On Fri, 2009-04-10 at 15:38 -0500, Nicolas Williams wrote:
> On Fri, Apr 10, 2009 at 03:17:18PM -0500, Nicolas Williams wrote:
> > After that long thread on SAAG and a subsequent off-list discussion with
> > Casey (plus my reading Smack documentation) I'm almost ready to reach
> > the following conclusions:
> 
> I should expand on this.  See below.
> 
> >  - We don't need policy agreement for MLS.  Servers have all the
> >    necessary information when comparing labels without reference to a
> >    policy.  However, clients have to be sharing a common MLS policy.
> 
> Which means DOI + label in CALIPSO-like label representation is
> sufficient.  DOI + opaque label is also good enough for MLS if the DOI
> can be used to find the label representation.
> 
> >  - For "smart" MLS and Smack servers we need a method by which servers
> >    can determine the label range/set of client and user principals, but
> >    this need not be specified in a standard way except where label
> >    range/set is borne by authentication credentials (Kerberos V ticket
> >    authorization-data, PKIX cert extensions).
> > 
> >    This is already described in my RPCSEC_GSSv3 document.
> 
> Which means we can proceed with this RPCSEC_GSSv3 aspect of labeled NFS.
> 
> Of course, it's not clear yet that it will be of much practical value to
> have such smart servers (e.g., if all the clients would be fully trusted
> anyways).  It may be possible that "dumb" servers are good enough, in
> which case we don't need to complicate RPCSEC_GSSv3 with process label
> assertions (though it's not much of a complication, but the client does
> need to know, via an NFS operation, whether the server is smart or
> dumb).

It is unclear to me why an NFS operation is needed for this. Why can't
this be something that is negotiated in the GSS context? When the GSS
context is created they can decide if the server is smart or not and if
it is then the process label is something that is part of the context.
Then when the server is making a decision if it is Smart it will use the
credential from the GSS context if not it will ignore it.

> 
> >  - For Smack we don't need policy agreement either, but it will be
> >    useful to distribute common subsets of Smack policy to clients, and
> >    to prefix labels from local-only sub-policies with a client ID (or
> >    client DOI, if you wish).
> 
> Which means we may want to have DOI + opaque label, and, perhaps, DOI +
> client ID + opaque label (but a client ID can be in the opaque label).
> 
> It should be noted that Smack does have a way to encode Smack labels as
> CIPSO MLS labels, though it is a hack.  We could similarly represent
> Smack labels via whatever MLS label representation we use -- but it'd be
> better (i.e., not hacky) to just have opaque labels for Smack.
> 
> >  - For DTE I've no idea what to do.  Policy agreement seems like a
> >    flight of fancy for DTE.  But *much* more importantly, because the
> >    process label transitions can span so many labels we simply cannot
> >    have too smart a server: the server can't meaningfully constrain the
> >    labels that a user@client can assert, therefore the server must trust
> >    all client assertions of process DTE labels or none at all.
> > 
> >    I.e., for DTE we can only have "dumb" servers.
> 
> Which means that for DTE we should have DOI + opaque label and all the
> server does is store them.  The server would not enfore DTE policies:
> only clients would.  Of course, the server can have share-level ACLs to
> decide which clients are trusted, but the server remains dumb.
> 
> 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] my thoughts on how Labeled NFSv4 draft should move forward

[Nicolas Williams]

On Tue, Apr 14, 2009 at 11:59:29AM -0400, David P. Quigley wrote:
> On Fri, 2009-04-10 at 15:38 -0500, Nicolas Williams wrote:
> > Of course, it's not clear yet that it will be of much practical value to
> > have such smart servers (e.g., if all the clients would be fully trusted
> > anyways).  It may be possible that "dumb" servers are good enough, in
> > which case we don't need to complicate RPCSEC_GSSv3 with process label
> > assertions (though it's not much of a complication, but the client does
> > need to know, via an NFS operation, whether the server is smart or
> > dumb).
> 
> It is unclear to me why an NFS operation is needed for this. Why can't

It could be an attribute.  That's how a variety of things are negotiated
already.

> this be something that is negotiated in the GSS context? When the GSS
> context is created they can decide if the server is smart or not and if
> it is then the process label is something that is part of the context.
> Then when the server is making a decision if it is Smart it will use the
> credential from the GSS context if not it will ignore it.

I'm thinking that the server could even be selectively smart or dumb.
For example, for objects labeled with MLS the server could be smart.
For objects labeled with Smack the server could be smart if it can
retrieve the rules matched by the client process' label's DOI.  For
objects with DTE labels in a DOI where the number of domains is too
large for it to be meaningful for the server to be smart then the server
could be dumb.

A filesystem attribute seems potentially too coarse for this, but it
could be a per-object attribute.

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] my thoughts on how Labeled NFSv4 draft should move forward

[Stephen Smalley]

On Fri, 2009-04-10 at 15:17 -0500, Nicolas Williams wrote:
> After that long thread on SAAG and a subsequent off-list discussion with
> Casey (plus my reading Smack documentation) I'm almost ready to reach
> the following conclusions:
> 
>  - We don't need policy agreement for MLS.  Servers have all the
>    necessary information when comparing labels without reference to a
>    policy.  However, clients have to be sharing a common MLS policy.

That is too limiting.  Think coalitions.

>  - For "smart" MLS and Smack servers we need a method by which servers
>    can determine the label range/set of client and user principals, but
>    this need not be specified in a standard way except where label
>    range/set is borne by authentication credentials (Kerberos V ticket
>    authorization-data, PKIX cert extensions).
> 
>    This is already described in my RPCSEC_GSSv3 document.
> 
>  - For Smack we don't need policy agreement either, but it will be
>    useful to distribute common subsets of Smack policy to clients, and
>    to prefix labels from local-only sub-policies with a client ID (or
>    client DOI, if you wish).
> 
>  - For DTE I've no idea what to do.  Policy agreement seems like a
>    flight of fancy for DTE.  But *much* more importantly, because the
>    process label transitions can span so many labels we simply cannot
>    have too smart a server: the server can't meaningfully constrain the
>    labels that a user@client can assert, therefore the server must trust
>    all client assertions of process DTE labels or none at all.
> 
>    I.e., for DTE we can only have "dumb" servers.

Why?  While it is certainly true that a given client may be authorized
to assert numerous discrete domains, that does not mean that a server
cannot limit a client to a specific set of domains.  That can be modeled
via a permission check on a label pair and security class, just like
everything else.

-- 
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] my thoughts on how Labeled NFSv4 draft should move forward

[Nicolas Williams]

On Mon, Apr 13, 2009 at 09:19:17AM -0400, Stephen Smalley wrote:
> On Fri, 2009-04-10 at 15:17 -0500, Nicolas Williams wrote:
> > After that long thread on SAAG and a subsequent off-list discussion with
> > Casey (plus my reading Smack documentation) I'm almost ready to reach
> > the following conclusions:
> > 
> >  - We don't need policy agreement for MLS.  Servers have all the
> >    necessary information when comparing labels without reference to a
> >    policy.  However, clients have to be sharing a common MLS policy.
> 
> That is too limiting.  Think coalitions.

I wrote that we don't _need_ policy agreement for MLS, not that we
couldn't use it if it were available.  A subtle distinction, I know :)
But you're right of course, that when label equivalencies come in we
then need policy agreement.

> >    I.e., for DTE we can only have "dumb" servers.
> 
> Why?  While it is certainly true that a given client may be authorized
> to assert numerous discrete domains, that does not mean that a server
> cannot limit a client to a specific set of domains.  That can be modeled
> via a permission check on a label pair and security class, just like
> everything else.

If the set of domains that a policy defines is enormous then it may be
difficult to limit the set of domains that a user@client could
reasonably claim when referring to objects on given file server.  IF
(and this is a big 'if' for me) the number of domains that a user@client
could assert cannot be constrained meaningfully then I don't see the
point of the server enforcing MAC: the server wouldn't be meaningfully
limiting what the client can do, therefore we might as well let the
client enforce MAC.

However, I imagine that much of any DTE policy is local-only -- that it
relates to system components like, say, passwd(1), or to user apps that
won't be straying outside a home directory or a sandbox therein.  If
local-only subsets of a DTE policy can be identified as such, and if
it's possible for the remainder to be shared by a DOI, and if it's
possible to ascertain what domains any user and any client can assert,
then we're back to where we can have a smart server.

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] my thoughts on how Labeled NFSv4 draft should move forward

[Casey Schaufler]

Stephen Smalley wrote:
>> ...
>>
>>  - For DTE I've no idea what to do.  Policy agreement seems like a
>>    flight of fancy for DTE.  But *much* more importantly, because the
>>    process label transitions can span so many labels we simply cannot
>>    have too smart a server: the server can't meaningfully constrain the
>>    labels that a user@client can assert, therefore the server must trust
>>    all client assertions of process DTE labels or none at all.
>>
>>    I.e., for DTE we can only have "dumb" servers.
>>     
>
> Why?  While it is certainly true that a given client may be authorized
> to assert numerous discrete domains, that does not mean that a server
> cannot limit a client to a specific set of domains.  That can be modeled
> via a permission check on a label pair and security class, just like
> everything else.
>   

I think that the point is that for that to be interesting you need
to have a significant number of subject-label/object-label/class
triples from the client available on the server. Additionally, it
assumes that the object label available to the server is in fact
the label from that client, not the server, and not a different
client. Unless you can map the object label on the file, wherever
it originated, to a label that is appropriate to the client's
policy. And heaven forbid that the client that "owns" the label
on the file should change it's policy and reboot. Now what you have
is at best no mapping, and at worst a mapping that reflects the
old, no longer considered "secure" policy.


--
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] my thoughts on how Labeled NFSv4 draft should move forward

[Nicolas Williams]

On Mon, Apr 13, 2009 at 09:02:22PM -0700, Casey Schaufler wrote:
> Stephen Smalley wrote:
> >>    I.e., for DTE we can only have "dumb" servers.
> >
> > Why?  While it is certainly true that a given client may be authorized
> > to assert numerous discrete domains, that does not mean that a server
> > cannot limit a client to a specific set of domains.  That can be modeled
> > via a permission check on a label pair and security class, just like
> > everything else.
> 
> I think that the point is that for that to be interesting you need
> to have a significant number of subject-label/object-label/class
> triples from the client available on the server. Additionally, it
> assumes that the object label available to the server is in fact
> the label from that client, not the server, and not a different
> client. Unless you can map the object label on the file, wherever
> it originated, to a label that is appropriate to the client's
> policy. And heaven forbid that the client that "owns" the label
> on the file should change it's policy and reboot. Now what you have
> is at best no mapping, and at worst a mapping that reflects the
> old, no longer considered "secure" policy.

My point was different.

With MLS and Smack there's typically a small number of process labels
that a given user on a given client could claim, and these labels could
be listed in a directory or in the client's and user's cryptographic
credentials.  Therefore the server can simply reject any assertions of
process labels outside the allowable set of labels for the given
user@client.

With DTE there may be an enormous number of domains (process labels),
and since these domains relate to domain transition rules that are very
much local affairs to the client, the server can only trust what the
client says.  Now, I do exagerate since DTE can express MLS-type
policies -- it's possible that there is a small set of domains that a
given user@client could assert meaningfully to a server, in which case
DTE would be on par with MLS and Smack.  The problem lies in identifying
that small set of domains relevant to server-enforced MAC, and making
sure that such small sets of domains exist.

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.