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;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: question about labeled NFS+rfc7569+selinux
From:   Thomas Haynes <loghyr@gmail.com>
In-Reply-To: <CAN-5tyFAc0R=D0OL2WHkKacTMW0JxKmLoqv2A2Et2gg5G6gjtQ@mail.gmail.com>
Date:   Thu, 5 Nov 2020 23:55:33 -0800
Cc:     NFSv4 <nfsv4@ietf.org>, linux-nfs <linux-nfs@vger.kernel.org>,
        earsh@netapp.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7C9450B-5782-4F1D-9F32-86D8B31820A0@gmail.com>
References: <CAN-5tyFAc0R=D0OL2WHkKacTMW0JxKmLoqv2A2Et2gg5G6gjtQ@mail.gmail.com>
To:     Olga Kornievskaia <aglo@umich.edu>
Precedence: bulk


> On Nov 5, 2020, at 11:47 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
>=20
> Hi folks,
>=20
> I would like to know if somebody can comment on the following
> regarding labeled NFS.
>=20
> RFC 7569 talks about Label formats and specifically lists that "0" is
> a reserved value.
>=20
> 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)
>=20
> 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?
>=20
> 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).
>=20
> 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?
>=20
> Thank you.

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=20=