2020-11-10 15:37:07

by Olga Kornievskaia

[permalink] [raw]
Subject: Re: [nfsv4] question about labeled NFS+rfc7569+selinux

Tom, David, thank you for the comments. Thank you for confirmation
that Selinux is misbehaving. I think it's unlikely we can fix the
Selinux. I'm not sure if this is Selinux's "default" label format
number and if another label would use a different number. I actually
hope not, I hope they consistently choose 0 for the format. Otherwise,
I think it would be impossible for the server to create a "default"
label for a file that was created by another non-MAC-aware client. I
think in this case, the server would need to determine/know that this
volume has Selinux formatted for their files and create a default
Selinux label.

On Fri, Nov 6, 2020 at 5:17 AM David Noveck <[email protected]> wrote:
>
>
>
> On Friday, November 6, 2020, Thomas Haynes <[email protected]> wrote:
>>
>>
>>
>> > On Nov 5, 2020, at 11:47 AM, Olga Kornievskaia <[email protected]> wrote:
>> >
>> > Hi folks,
>> >
>> > I would like to know if somebody can comment on the following
>> > regarding labeled NFS.
>
>
> I can comment but "oh, gee. What a godamn mess!" Is probably not what you are looking for.
>
>>
>> >
>> > RFC 7569 talks about Label formats and specifically lists that "0" is
>> > a reserved value.
>> >
>> > Using labeled NFS with SElinux and looking at labels (in wireshark),
>> > the selinux sends sends/sets label format as 0 (ie. this is a reserved
>> > value according to the spec)
>> >
>> > So we have labelformat_spec4 set to 0 where the spec says this field
>> > "The LFS and the Security Label Format Selection Registry are
>> > described in detail in [RFC7569]". It's unlikely that "0" reserved
>> > for Selinux and not explicitly specified there?
>> >
>> > 0 seems to be a good choice for using as a default label which the
>> > RFC7862 vaguely talks about (though says nothing about the format for
>> > a default label).
>
>
> Does Selinux use 0 as the selector only for default labels, or does it use it for other, non-default labels?. I'm assuming default labels would just consist of the zero selector and nothing else.
>>
>> >
>> > I'm not aware if Selinux is supposed to follow a spec and
>
>
> We'll it is said to support the labeled NFS feature and that probably means it makes at least some attempt to follow the relevant specs.
>>
>>
>> therefore I
>> > don't think it is obligated to follow the rules of RFC 7569.
>
>
> The IETF has no enforcement powers.
>>
>>
>> Anybody
>> > can comment how labeled NFS label format and SElinux label format
>> > choice are supposed to co-exist?
>
>
> I guess it wasn't really thought about.
>
> They have co-existed so far by others staying away from zero and by Selinux using nothing else.
>>
>> >
>> > Thank you.
>>
>> Hi Olga,
>>
>> The SELinux implementation of Labeled NFS is not spec compliant.
>
>
> Good to know.
>
>>
>>
>> There are two paths forward:
>
>
> I think both of them run into difficulties.
>>
>>
>> 1) Fix the implementation to be spec compliant.
>
>
> Not sure how that would be done or who would do it. Even apart from compatibility issues with the legacy non-compliant implementation, this is non-trivial.
> ..
>
>> 2) File an errata to RFC 7569 to allow 0 to be assigned to the SELinux implementation.
>
>
> That errata report would have to be rejected as it revises an existing working group consensus. The alternative would be a new working group consensus with an RFC updating or obsoleting RFC 7569. There is nobody to do that work and I'm pretty sure we'd run into the issue we ran into with integrity measurement in which getting a specification for a piece of Linux implementation becomes a difficult and thankless task.
>
> I think we will just leave this as it is. A new security document would have to mention it but only to say this is a troubled area that will eventually need working group. Attention. Sigh!
>>
>>
>> The argument against 1) is that there are existing deployments of servers and clients which will be incompatible.
>
>
> One of many issues with this.
>>
>>
>> Thanks,
>> Tom
>> _______________________________________________
>> nfsv4 mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nfsv4