Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt

[Chuck Lever <[e-mail]>]

> On Sep 27, 2018, at 11:21 AM, Everhart, Craig <[e-mail]> wrote:
> 
> Sigh--great sadness.
> 
> How do I tell whether NFS security labels are MAC or SMACK or one of their friends?
> 
> Why wait for a collision before specifying how a choice of label formats is represented?

It's a design philosophy. Avoid overdesign -- don't add something now that you don't need now. I can't think of a use case where you'd want
to have multiple concurrent mechanisms for assessing file integrity.

We could add an LFS-like identifier and an IANA registry, and we'll
have just one entry in it forever.

If you know of a specific potential user of this mechanism that is
not IMA, I'll reconsider.




> 		Craig
> 
> 
> On 9/27/18, 2:11 PM, "Chuck Lever" <[e-mail]> wrote:
> 
>    Hi Craig-
> 
>> On Sep 27, 2018, at 9:59 AM, Everhart, Craig <[e-mail]> wrote:
>> 
>> Just to say: when there was the "8-bit-transparent" scheme around, it LOST to the UTF encoding.  Without knowing what the local character scheme was, it made no sense to claim interoperability with some other unspecified character encoding scheme.
>> 
>> The analogy here is that you're either trying to reserve an "8-bit-clean" repository of opaque data, where a server doesn't know what it's storing and a separate client has no idea what it's seeing, or you're trying to reserve a particular slot for the sole use of some format that you don't describe.  In that second case, the analogy with file name data isn't so clear: NFS is built around having exactly one (component) file name, without a label explaining how to interpret that file name label.
>> 
>> But you're effectively asking for private use of the "file provenance" name space.  I hope there's never another community that also comes up with a "file provenance" description scheme.
> 
>    We've already taken this route this with NFS security labels. There is
>    exactly one xattr that can store only _one_ of a MAC label, or SMACK,
>    or ...
> 
>    Both cases you describe above are serviceable via the mechanism
>    I proposed. If there ever is a collision, then the assessment
>    applications involved can use an XML wrapper to label and store
>    both types of FPI in the same slot, or they can approach the WG
>    and request another fattr4 attribute.
> 
>    Alternatively, an implementation may choose to have a security.ima
>    xattr for local consumers, and a separate xattr that stores FPI
>    consumed by remote users.
> 
> 
>>              Craig
>> 
>> 
>> 
>> On 9/27/18, 12:24 PM, "Chuck Lever" <[e-mail]> wrote:
>> 
>>> On Sep 27, 2018, at 9:09 AM, Everhart, Craig <[e-mail]> wrote:
>>> 
>>> This exact issue needs to be discussed in the draft--whether it makes sense for clients/servers that don't a-priori recognize the "file provenance" information to reject the communication, and how.  Should non-recognizing servers store the information blind?  Or should they reject such files?
>> 
>>   Good point. I can add language that fills that in. In fact
>>   that will be a copy-and-paste from an earlier version of
>>   this document.
>> 
>> 
>>> Essentially, the draft seems to imply that there's a well-understood way that some community of file handlers has of describing file provenance.  Instead of explaining what that is, the author(s) of the draft simply want to standardize a way of describing data that is otherwise opaque.  The draft gives no information on how to construct an appropriate file-provenance blob of bits, to my reading, or to explain what a formatted blob of bits would mean.
>>> 
>>> Let's say that there are multiple communities that all are composed of people that understand some formatting scheme.  How should they interact?  How would I (a file server) take a blob from community A and present it in a way that community B would understand?  Or is this formatting scheme to remain opaque forever?
>>> 
>>> We had an analogous tussle many years ago with the "8-bit-transparent" file name stuff.  One community wanted NFS to simply save file names in their full 8-bit form, without interpretation.  That's fine as long as everybody who sees a given name knows how to interpret it.  (This was in the days before UTF-8 or its analogues; we had a lot of localized character sets that people wanted to use verbatim.)  Thank heavens that we no longer have that particular fight.  But this draft feels analogous: it apparently wants NFS to store and retrieve "provenance" blobs without altering them, saying that they have meaningful semantics, but without explaining what those semantics are.
>> 
>>   Yes, that's what we want to do. This is exactly the same
>>   as storing opaque file data. NFS is conveying and storing
>>   data on behalf of an application which is responsible for
>>   interpreting that data.
>> 
>> 
>>>             Craig Everhart
>>> 
>>> 
>>> 
>>> On 9/27/18, 11:32 AM, "nfsv4 on behalf of Chuck Lever" <[e-mail] on behalf of [e-mail]> wrote:
>>> 
>>>  The consequences of not recognizing the file provenance information
>>>  are not dire. In those cases, clients simply don't allow access to
>>>  the file's content, and the implementations are free to report to
>>>  the administrator that the FPI format is not recognized.
>>> 
>>>  Would it help to state that in the draft?
>>> 
>> 
>>   --
>>   Chuck Lever
>> 
>> 
>> 
>> 
>> 
> 
>    --
>    Chuck Lever
> 
> 
> 
> 
> 

--
Chuck Lever