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

[Jarrett Lu <Jarrett.Lu@sun.com>]

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.