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

From: Olga Kornievskaia <[email-masked]>
Date: Thu, 5 Nov 2020 14:47:41 -0500

Hi folks,

I would like to know if somebody can comment on the following
regarding labeled NFS.

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).

I'm not aware if Selinux is supposed to follow a spec and therefore I
don't think it is obligated to follow the rules of RFC 7569. Anybody
can comment how labeled NFS label format and SElinux label format
choice are supposed to co-exist?

Thank you.

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 5 Nov 2020 23:55:33 -0800

> On Nov 5, 2020, at 11:47 AM, Olga Kornievskaia <[email-masked]> wrote:
> 
> Hi folks,
> 

Hi Olga,

The SELinux implementation of Labeled NFS is not spec compliant.

There are two paths forward:

1) Fix the implementation to be spec compliant.
2) File an errata to RFC 7569 to allow 0 to be assigned to the SELinux implementation.

The argument against 1) is that there are existing deployments of servers and clients which will be incompatible.

Thanks,
Tom

---

From: David Noveck <[email-masked]>
Date: Fri, 6 Nov 2020 05:17:24 -0500

> > I would like to know if somebody can comment on the following

I can comment but "oh, gee. What a godamn mess!" Is probably not what you
are looking for.

> > RFC7862 vaguely talks about (though says nothing about the format for

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

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.

> 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!

> and clients which will be incompatible.

One of many issues with this.

>
> Thanks,
> Tom
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 10 Nov 2020 10:35:50 -0500

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-masked]> wrote:
> I can comment but "oh, gee. What a godamn mess!" Is probably not what you are looking for.
>
>>
>> >
> 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.
>>
>> >
> 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
> They have co-existed so far by  others staying away from zero and by Selinux using nothing else.
>>
>> >
>> > Thank you.
>>
>> Hi Olga,
>>
> 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.
> ..
>
> 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!
>>
>>