Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAN-5tyFAc0R=D0OL2WHkKacTMW0JxKmLoqv2A2Et2gg5G6gjtQ@mail.gmail.com>
 <C7C9450B-5782-4F1D-9F32-86D8B31820A0@gmail.com> <CADaq8jd=hKm7omSa26EN7R6nbsifpsmJHkBxixMYuH1M_4nb=w@mail.gmail.com>
In-Reply-To: <CADaq8jd=hKm7omSa26EN7R6nbsifpsmJHkBxixMYuH1M_4nb=w@mail.gmail.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Tue, 10 Nov 2020 10:35:50 -0500
Message-ID: <CAN-5tyFXsHeNjryYGk=sDWwXMjMznPeNYsGGnbTUPK_MYaPgxg@mail.gmail.com>
Subject: Re: [nfsv4] question about labeled NFS+rfc7569+selinux
To:     David Noveck <davenoveck@gmail.com>
Cc:     Thomas Haynes <loghyr@gmail.com>,
        "earsh@netapp.com" <earsh@netapp.com>,
        linux-nfs <linux-nfs@vger.kernel.org>, NFSv4 <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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 <davenoveck@gmail.com> wrote:
>
>
>
> On Friday, November 6, 2020, Thomas Haynes <loghyr@gmail.com> wrote:
>>
>>
>>
>> > On Nov 5, 2020, at 11:47 AM, Olga Kornievskaia <aglo@umich.edu> 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 u=
se it for other, non-default labels?. I'm assuming default labels would jus=
t 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 mea=
ns 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 Seli=
nux 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 compa=
tibility issues with the legacy non-compliant implementation, this is non-t=
rivial.
> ..
>
>> 2) File an errata to RFC 7569 to allow 0 to be assigned to the SELinux i=
mplementation.
>
>
> That errata report would have to be rejected as it revises an existing wo=
rking group consensus.  The alternative would be a new working group consen=
sus with an RFC updating or obsoleting RFC 7569.   There is nobody to do th=
at work and I'm pretty sure we'd run into the issue we ran into with integr=
ity measurement in which getting a specification for a piece of Linux imple=
mentation 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 even=
tually need working group. Attention.  Sigh!
>>
>>
>> The argument against 1) is that there are existing deployments of server=
s and clients which will be incompatible.
>
>
> One of many issues with this.
>>
>>
>> Thanks,
>> Tom
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4