Security labeling in NFS4 - who owns it?

Security labeling in NFS4 - who owns it?

[Casey Schaufler]

As part of my work on LSM stacking I've encountered some issues with
the Linux implementation of NFS4 security labels. For example, the LFS
data is ignored, so even if the client and server are willing to identify
the kind of information they are passing, the identity information isn't
available. The code asks if attributes requested are mandatory access
control attributes, but cannot differentiate between which of the possible
security attribute the other end is providing.

Is anyone actively owing the NFS labeling code? I'd like to bounce an
idea or two around before committing too much time to my ideas of
solutions.

 

Re: Security labeling in NFS4 - who owns it?

[Paul Moore]

On Thu, Aug 1, 2019 at 3:39 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> As part of my work on LSM stacking I've encountered some issues with
> the Linux implementation of NFS4 security labels. For example, the LFS
> data is ignored, so even if the client and server are willing to identify
> the kind of information they are passing, the identity information isn't
> available. The code asks if attributes requested are mandatory access
> control attributes, but cannot differentiate between which of the possible
> security attribute the other end is providing.
>
> Is anyone actively owing the NFS labeling code? I'd like to bounce an
> idea or two around before committing too much time to my ideas of
> solutions.

I guess it all depends on what you mean by "own".  Historically it has
been a mix of the NFS and SELinux folks that have worked on it and
contributed patches, with code sprinkled between the two subsystems
(and possibly elsewhere too).

I suspect a better question would be: who should you work with to
discuss issues the labeled NFS code?  I don't want to assume too much,
but I think you know the answer to that one already ;)

-- 
paul moore
www.paul-moore.com

Re: Security labeling in NFS4 - who owns it?

[Casey Schaufler]

On 8/1/2019 3:02 PM, Paul Moore wrote:
> On Thu, Aug 1, 2019 at 3:39 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> As part of my work on LSM stacking I've encountered some issues with
>> the Linux implementation of NFS4 security labels. For example, the LFS
>> data is ignored, so even if the client and server are willing to identify
>> the kind of information they are passing, the identity information isn't
>> available. The code asks if attributes requested are mandatory access
>> control attributes, but cannot differentiate between which of the possible
>> security attribute the other end is providing.
>>
>> Is anyone actively owing the NFS labeling code? I'd like to bounce an
>> idea or two around before committing too much time to my ideas of
>> solutions.
> I guess it all depends on what you mean by "own".  Historically it has
> been a mix of the NFS and SELinux folks that have worked on it and
> contributed patches, with code sprinkled between the two subsystems
> (and possibly elsewhere too).
>
> I suspect a better question would be: who should you work with to
> discuss issues the labeled NFS code?  I don't want to assume too much,
> but I think you know the answer to that one already ;)

I know you have many balls in the air and don't want to pester you
with every issue, but since you (sort of) volunteered ...

The labeled NFS code provides support for a single "security label".
When an extended attribute (xattr) is requested on an NFS4.2 or later
filesystem the NFS code calls security_ismaclabel(attrname) to determine
if the requested attrname is recognized as the name of the one attribute
whose value is maintained as the "security label". This works swimmingly
so long as all the NFS servers and all the NFS clients are sharing the
same attrname.

On a system with multiple security modules that provide ismaclabel hooks
we encounter ambiguity. If SELinux and Smack are both available
security_ismaclabel("selinux") and security_ismaclabel("SMACK64") will
both return success, and the NFS xattr code will set/get the network
resident value for either. Of course, only one can be correct, but there
does not appear to be any way to determine which it is. The protocol
provides an "LFS" to identify format the data being transmitted, but
it is not used in the Linux implementation.

It is reasonable (to the extent running SELinux and Smack together is
reasonable) for a program to ask for all the security attributes on a
file. It would be perfectly reasonable for a program like ls or systemd
to ask for both values.

There's an easy workaround, which is to assume that the first security
module that provides the ismaclabel hook will be the NFS using LSM.
Or, that the last security module with a hook gets the data. A slightly
more difficult option is to have a mount option ( -o nfslsm=selinux )
or a system wide setting (echo selinux > /sys/kernel/security/nfslsm)
or some other way to tell the system which to do.

Adding LFS management could be tricky in light of the compatibility
issues that will arise when talking to a server that doesn't do it.

I'm looking at it makes sense to "fix" the NFS implementation
to identify the data format with the LFS value. That is probably a
bigger job than I want to take on. If not, I solicit opinions regarding
which of the workarounds is most likely to be agreeable.