[nfs-discuss] [nfsv4] New MAC label support Internet Draft posted to IETF website
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. > 0x000300a 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
[nfs-discuss] [nfsv4] New MAC label support Internet Draft posted to IETF website
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 implem
[nfs-discuss] [nfsv4] New MAC label support Internet Draft posted to IETF website
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 configur
[nfs-discuss] [nfsv4] New MAC label support Internet Draft posted to IETF website
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 --
[nfs-discuss] [nfsv4] New MAC label support Internet Draft posted to IETF website
On Fri, Jan 23, 2009 at 11:37:37AM -0600, 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 at 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. I can't speak for Sun's Solaris Trusted Extensions team, but as an individual I believe this work is important and should proceed. And while this work could well proceed outside the NFSv4 WG as individual submission Internet-Drafts, I believe these documents will greatly benefit, in terms of quality and time-to-publication, by being covered by the NFSv4 WG charter. Therefore I support amending the WG's charter to include work on MAC labeling support in NFSv4. Cheers, Nico --
[nfs-discuss] [nfsv4] New MAC label support Internet Draft posted to IETF website
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 at 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 at tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message.
