Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

From: Tom Haynes <[email-masked]>
Date: Wed, 2 May 2018 14:30:14 -0700

Hey Chuck,

For the most part, my issues are the ones common to first drafts.

And Spencer S, 

Can we nominate this as official WG document? It is mature enough and on point with the earlier LFS work.

Thanks,
Tom

Abstract

NFS version 4.2 
Need to define NFS first.

Introduction

Before specifying new protocol,
->

Before specifying a new protocol,
—

(hereafter, IMA)
(hereafter, EVM)
drop the hereafters

—

This is done by cryptographically signing HMAC
please introduce HMAC
--
RSA public key signature
Please define RSA

——

The goals and use cases of the Linux Integrity Measurement
   Architecture (IMA) are presented in further detail in [IMA-WP].
Already have defined IMA

—

with the
   superuser 
What is a superuser?

——

You then have four bullet points, which as they are complete sentences should end with ‘.’

—

execve(2)

need a citation (probably to POSIX)

===

Section 3

Linux file capabilities
becomes
a capability set
without motivating the connection.

=====

LFS

not introduced.

====

MAC

not introduced

—

   In order to enable file capabilities to be retrieved or updated in a
   single RPC, the text format representation of a capability set MUST
   NOT exceed 8192 bytes in length.

   In order to enable IMA metadata to be retrieved or updated in a
   single RPC, a signed hash MUST NOT exceed 4096 bytes in length.
Why the restrictions? Is it a matter of the length of the compound?

——

a Merkle
citation?

——

An NFSv4 server is required to enforce a suitable level of privilege
   before allowing a local or remote agent to alter NFSv4 Security
   Labels.  Consult Section 9.6 of [RFC7862] for further details.

Is the last sentence a sentance?

——

Therefore additional protection using GSS
   [RFC7861] or other security mechanisms is not mandatory.

Either define GSS or perhaps say RPCSEC_GSS?

---

From: Chuck Lever <[email-masked]>
Date: Wed, 2 May 2018 17:36:16 -0400

> On May 2, 2018, at 5:30 PM, Tom Haynes <[email-masked]> wrote:
> 
> Hey Chuck,
> 

Tom, thanks for the review. I was planning to submit

  draft-cel-nfsv4-linux-seclabel-xtensions-01

next week with substantial clarifications and some corrections.
If the WG and Spencer approve your request, I can submit

  draft-ietf-nfsv4-linux-seclabel-xtensions-00

instead.

--
Chuck Lever

---

From: "Quigley, David" <[email-masked]>
Date: Wed, 2 May 2018 22:36:34 +0000

I can understand wanting to use the sec_label field for capabilities but using it for the IMA and EVM data isn’t really in the spirit of what we designed this for. Those are integrity mechanisms and on Linux systems they are completely separate from the LSMs (access control is not integrity).

Also having them as 3 different LFS ids make no sense. The LFS is supposed to describe the format of what you are sending and receiving for the sec_label field. Unless something changed in the last rounds of revisions to the sec_label support there should only be one value per file?

Also something to consider is that Nico explicitly separates capabilities from MAC labeling in in RPCSECGSSv3. This is because traditionally capabilities and MAC systems are orthogonal to each other. I know file capabilities are different from the regular capabilities on processes in Linux but it is something to consider that on a normal Linux system they can co-exist and be enforced at the same time. With this mechanism you couldn’t support both SELinux and file-capabilities at the same time like you could on a local system.

I will be able to provide better feedback once I’ve read through the document another couple of times but those are my initial impressions just from a sec_label and LFS perspective.

Dave

From: nfsv4 [mailto:[email-masked]] On Behalf Of Tom Haynes
Sent: Wednesday, May 2, 2018 3:30 PM
To: Chuck Lever <[email-masked]>; Spencer Shepler <[email-masked]>
Cc: NFSv4 <[email-masked]>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

Hey Chuck,

And Spencer S,

Thanks,
Tom

Abstract

NFS version 4.2

Introduction

(hereafter, IMA)

(hereafter, EVM)
drop the hereafters

—

--

RSA public key signature
Please define RSA

——

—

with the

   superuser
What is a superuser?

——

—

execve(2)

===

Section 3

Linux file capabilities

becomes

a capability set

=====

LFS

not introduced.

====

MAC

not introduced

—

——

a Merkle

citation?

——

——

---

From: Chuck Lever <[email-masked]>
Date: Wed, 2 May 2018 18:50:31 -0400

Hi David-

> On May 2, 2018, at 6:36 PM, Quigley, David <[email-masked]> wrote:
> 

Yep, I get that, but I don't see a functional problem here. It seems like
an artificial constraint to say that we can't store IMA metadata in a
generic security label, and I don't see any explicit prohibition to doing
so laid out in the existing RFCs (if there is one, please point it out).

You can make a similar argument about file capabilities, which are not
MAC security. Should they be excluded from using a security label for this
reason?

> Also having them as 3 different LFS ids make no sense. The LFS is supposed to describe the format of what you are sending and receiving for the sec_label field. Unless something changed in the last…

A file can have capabilities associated with it, a security.ima xattr, and
a security.evm xattr. All three are separate objects and can change
independently of each other. Capabilities and IMA are not at all related
to each other, so at least these two need separate LSF numbers.

> Also something to consider is that Nico explicitly separates capabilities from MAC labeling in in RPCSECGSSv3. This is because traditionally capabilities and MAC systems are orthogonal to each othe…

Implementations can store the content of each LSF in separate xattrs, or
so it appears from my brief audit of the Linux implementation. I don't see
anything that prevents storing an SELinux label in one xattr, file
capabilities in a second xattr, and IMA metadata in a third xattr.

> I will be able to provide better feedback once I’ve read through the document another couple of times but those are my initial impressions just from a sec_label and LFS perspective. 

Thanks for looking!

--
Chuck Lever

---

From: "Quigley, David" <[email-masked]>
Date: Wed, 2 May 2018 23:10:48 +0000

Hi Chuck,

I'll address each thing in turn since outlook doesn't seem to like inline commenting

I would say there is a prohibition on it as it was the only reason we went down the sec_label route in the first place. The initial proposal was to have xattrs on nfsv4 and put the security label in there. We designed the sec_label attr for MAC labels and the LFS specification is also explicitly for MAC Labels. We explicitly state that FATTR4_SEC_LABEL is a MAC Security Attribute in the 4.2 specification. This field is called sec_label which is kind of unfortunate name as it was intended to represent security labels in the traditional orange book sense.  It is not intended for arbitrary security related data. It is an access control field not an integrity field. Using it as a blob store for integrity data is similar to the pushback I received from Trond when I wanted to put this data in xattrs to begin with.

I also said I could see why you'd want to use it for capability data but to be honest capabilities should have their own mechanism just like how they do in Linux today. Its unfortunate that all of this is stores in xattrs on Linux because it really shouldn't be. The initial version of SELinux had new system calls for getting and setting security related information. It was only because the way of handling things at the time was to extend interfaces through the file system and psudo filesystems that SELinux and IMA look the way they do today. If you look at other systems that did it properly (FreeBSD) they introduced proper syscalls for all of this.

With respect to the three LFS numbers they are only supposed to cover data in the sec_label attribute. Do you only intend on storing one of the three in the attribute? How is this supposed to work? If you have a setfattr with an IMA LFS encoded attribute and then an EVM encoded attribute it would just overwrite it. You wouldn't be able to store them independently with the one attribute as it is unless I am misunderstanding something.

I will have to look at what was done with the final implementation that made its way into the Linux kernel but the sec_label attribute is supposed to be limited to one value per file. It is not supposed to be a multiplexed attribute based on the LFS. Security labels in a MAC sense are explicitly one value per file.

I will give it a closer read tonight and look at the implementation in the Linux Kernel. However it was not intended that if you do serfattr with two different lfs that you would store two different values.

Dave

-----Original Message-----
From: Chuck Lever [mailto:[email-masked]] 
Sent: Wednesday, May 2, 2018 4:51 PM
To: Quigley, David <[email-masked]>
Cc: Tom Haynes <[email-masked]>; Spencer Shepler <[email-masked]>; NFSv4 <[email-masked]>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

Hi David-

> I can understand wanting to use the sec_label field for capabilities but using it for the IMA and EVM data isn’t really in the spirit of what we designed this for. Those are integrity mechanisms an…

Yep, I get that, but I don't see a functional problem here. It seems like an artificial constraint to say that we can't store IMA metadata in a generic security label, and I don't see any explicit prohibition to doing so laid out in the existing RFCs (if there is one, please point it out).

You can make a similar argument about file capabilities, which are not MAC security. Should they be excluded from using a security label for this reason?

> Also having them as 3 different LFS ids make no sense. The LFS is supposed to describe the format of what you are sending and receiving for the sec_label field. Unless something changed in the last…

A file can have capabilities associated with it, a security.ima xattr, and a security.evm xattr. All three are separate objects and can change independently of each other. Capabilities and IMA are not at all related to each other, so at least these two need separate LSF numbers.

> Also something to consider is that Nico explicitly separates capabilities from MAC labeling in in RPCSECGSSv3. This is because traditionally capabilities and MAC systems are orthogonal to each othe…

Implementations can store the content of each LSF in separate xattrs, or so it appears from my brief audit of the Linux implementation. I don't see anything that prevents storing an SELinux label in one xattr, file capabilities in a second xattr, and IMA metadata in a third xattr.

Thanks for looking!

> Subject: Re: [nfsv4] New Version Notification for 
> draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
>  
> Hey Chuck,
>  
> This is done by cryptographically signing HMAC please introduce HMAC
> --
> RSA public key signature
> Please define RSA
>  
> ——
>  

--
Chuck Lever

---

From: "Quigley, David" <[email-masked]>
Date: Wed, 2 May 2018 23:11:01 +0000

Hi Chuck,

I would say there is a prohibition on it as it was the only reason we went down the sec_label route in the first place. The initial proposal was to have xattrs on nfsv4 and put the security label in there. We designed the sec_label attr for MAC labels and the LFS specification is also explicitly for MAC Labels. We explicitly state that FATTR4_SEC_LABEL is a MAC Security Attribute in the 4.2 specification. This field is called sec_label which is kind of unfortunate name as it was intended to represent security labels in the traditional orange book sense.  It is not intended for arbitrary security related data. It is an access control field not an integrity field. Using the 

-----Original Message-----
From: Chuck Lever [mailto:[email-masked]] 
Sent: Wednesday, May 2, 2018 4:51 PM
To: Quigley, David <[email-masked]>
Cc: Tom Haynes <[email-masked]>; Spencer Shepler <[email-masked]>; NFSv4 <[email-masked]>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

Hi David-

Thanks for looking!

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 2 May 2018 19:27:39 -0400

> On May 2, 2018, at 7:10 PM, Quigley, David <[email-masked]> wrote:
> 
> Hi Chuck,
> 

Let's dive into this one for a moment.

Are you saying that a file is allowed only one NFSv4 security label at a time,
similar to the way a file can have only one NFSv4 ACL?

If that's the case, then NFSv4 security labels are not going to work at all,
and we'll have to create a separate purpose-built mechanism for each of these
objects. Obviously we do need to store an ACL and an SELinux label and IMA
metadata and file capabilities separately.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 2 May 2018 19:32:23 -0400

I can fix up most of these in the next revision. See below for a
response on the question about size limits.

> This is done by cryptographically signing HMAC

 - The size of an NFS COMPOUND is limited
 - The underlying filesystem may have limits on the size of
   the physical object that stores this metadata
 - For transports like RDMA, provisioning a sink buffer is
   necessary before the RPC Call or Reply is sent
 - I'm not really anxious to build extra protocol elements and round
   trips to negotiate the size limits

In recent standards track documents we have avoided discussion
of rationale when specifying protocol, thus I excluded that
discussion here as well.

> Is the last sentence a sentance?

It's not a sentance, but it is a properly constructed sentence
in the imperative mood. :-p

--
Chuck Lever

---

From: Tom Haynes <[email-masked]>
Date: Wed, 2 May 2018 17:12:13 -0700

Hey Chuck,

For some reason I thought you were describing what Linux was doing, not something new...

But yeah, David is right, only one LFS is going to work.

I’ll have to check if xattrs allows for system atttrs, but if it does, why can’t you use them?

Tom

> On May 2, 2018, at 4:27 PM, Chuck Lever <[email-masked]> wrote:
> 
> 
>

---

From: Chuck Lever <[email-masked]>
Date: Thu, 3 May 2018 09:49:00 -0400

> On May 2, 2018, at 8:12 PM, Tom Haynes <[email-masked]> wrote:
> 
> Hey Chuck,
> 

Hi Tom-

NFSv4 xattrs expose only the user namespace. xattrs in the security.yada namespace
are not exposed to NFS clients, for example.

Initially we were thinking of using NFSv4 security labels only for experimentation,
but there didn't seem to be any reason not to use them for the long-term solution.
Since it now appears that there can't be a separate label for security.ima and
security.evm, that makes it challenging to use security labels even for
experimentation.

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

--
Chuck Lever

---

From: [email-masked] (J. Bruce Fields)
Date: Thu, 3 May 2018 11:03:15 -0400

On Wed, May 02, 2018 at 06:50:31PM -0400, Chuck Lever wrote:
> > On May 2, 2018, at 6:36 PM, Quigley, David <[email-masked]>
> > wrote: Also having them as 3 different LFS ids make no sense. The
> > LFS is supposed to describe the format of what you are sending and
> > receiving for the sec_label field. Unless something changed in the
> > last rounds of revisions to the sec_label support there should only
> > be one value per file?
> 
> A file can have capabilities associated with it, a security.ima xattr,
> and a security.evm xattr. All three are separate objects and can
> change independently of each other. Capabilities and IMA are not at
> all related to each other, so at least these two need separate LSF
> numbers.

The client doesn't have a way to query them separately.  All you can do
is send a GETATTR {FATTR4_SEC_LABEL}, and then the server can only
return one thing.  So, I agree, overloading the security labels in this
way doesn't work.  I overlooked that!

It's no problem to define a couple new attributes instead, let's just do
that.  That will also give clients an easy way to query for IMA or
file capability support by querying the supported_attrs attributes.

--b.

---

From: [email-masked] (J. Bruce Fields)
Date: Thu, 3 May 2018 11:05:22 -0400

> of rationale when specifying protocol, thus I excluded that

Let's stop doing that.  Rationale is really important, and putting it in
the RFC is the best way to ensure it's not lost.

--b.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 3 May 2018 11:13:39 -0400

> On May 3, 2018, at 11:03 AM, J. Bruce Fields <[email-masked]> wrote:
> 

That's what I was thinking too. Dave's extensibility work should make it
straightforward to add these new attributes.

In terms of I-Ds, perhaps I should specify the new IMA and file capabilities
attributes in separate documents. Is it still reasonable to submit the first
revision of these as WG documents rather than personal drafts?

--
Chuck Lever

---

From: [email-masked] (J. Bruce Fields)
Date: Thu, 3 May 2018 11:13:32 -0400

On Wed, May 02, 2018 at 10:36:34PM +0000, Quigley, David wrote:
> Also having them as 3 different LFS ids make no sense. The LFS is
> supposed to describe the format of what you are sending and receiving
> for the sec_label field.

By the way, something Chuck noticed is that the Linux client and server
implementations are completely ignoring the LFS field--they always
discard it when receiving, and set it to 0 when sending.  I assume we
should at least fix them to reject non-zero values for now.

--b.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 3 May 2018 08:31:34 -0700

> On May 3, 2018, at 8:13 AM, J. Bruce Fields <[email-masked]> wrote:
> 

Actually, that is a bug in the Linux implementation!

According to RFC7569, a LFS of 0 is reserved.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 3 May 2018 08:42:43 -0700

> On May 3, 2018, at 6:49 AM, Chuck Lever <[email-masked]> wrote:
> 
> 
> 
>> On May 2, 2018, at 8:12 PM, Tom Haynes <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hey Chuck,
>> 

No, they are not challenging to use for experimentation if you are using LNFS as designed.

I.e., someone can go in and implement a new Label Format Specifier and use 128 - 255.

BTW, it is also the case that you could not use LFS values of 1, 2, and 3 as described in RFC7569.
The allowed new values start at 260.

---

From: Bruce Fields <[email-masked]>
Date: Thu, 3 May 2018 11:46:59 -0400

> According to RFC7569, a LFS of 0 is reserved.

If there's something else we should be using, we could modify them to
send that and reject anything that's not that or zero.

We're stuck with the zero now, though, alas.

--b.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 3 May 2018 13:10:16 -0400

> On May 3, 2018, at 11:42 AM, Tom Haynes <[email-masked]> wrote:
> 
> 
> 

I meant:

It is challenging to use NFSv4 security labels to experiment with IMA,
because IMA requires storing two independent metadata objects per file.

To experiment, I would need to find a way of encoding both objects so
that they could be stored together in the same label. That potentially
introduces a read-modify-write cycle if a client wants to update just
one of those objects.

> I.e., someone can go in and implement a new Label Format Specifier and use 128 - 255.

However if the existing seclabel implementation (Linux) does not pay
attention to or store the LSF values, there is already an interoperability
problem with experimental implementations, isn't there? That can be
fixed, though.

> The allowed new values start at 260.

The range past 255 appears to be for MAC content. I chose LFS values in
the reserved range because both IMA and file capabilities are not MAC,
similar to SELinux contexts, which appears to use reserved value 0.
I was told that SELinux is not MAC.

All academic now. I think everyone would be more comfortable with new
fattr4 attributes rather than abusing security labels, so I will pursue
the former instead.

Thanks for your review!

--
Chuck Lever

---

From: "Quigley, David" <[email-masked]>
Date: Thu, 3 May 2018 21:58:30 +0000

The issue is the only one defined at the moment in the LFS registry is the flask one. Casey doesn't have a number assigned for a SMACK label format so I believe that is why we have 0 used. When Jarret and I wrote the LFS document I believe the intent of id 0 was that this was a null identifier which was to be taken as no format specified. Essentially it would just be raw data. This seems to not have been codified in the actual document and it is not clear why that is the case. In my initial implementation before someone else took over I had a daemon similar to the old idmapd called doimapd which filled in the LFS field properly. Ideally when the kernel goes to package up the attribute it would see what LSM it is using and that LSM would provide it with a valid LFS structure for the attribute. On the other end it would understand the LFS structure and be able to unpack it.

>From an implementation standpoint I don't think this is an issue because what it means currently is the MAC on both the client and server have to match. In the future this could be changed so an intermediate daemon handles the label and policy translation. Ideally an SELinux enabled server could receive a request from a Trusted Solaris (I think its trusted extensions now) and be able to retain the MLS portion of the label and just assign an arbitrary SELinux label. This wasn't implemented or attempted as Linux is the only Labeled NFS implementation at the moment but that was the intent.

Dave

-----Original Message-----
From: Bruce Fields [mailto:[email-masked]] 
Sent: Thursday, May 3, 2018 9:47 AM
To: Tom Haynes <[email-masked]>
Cc: Quigley, David <[email-masked]>; Chuck Lever <[email-masked]>; Spencer Shepler <[email-masked]>; NFSv4 <[email-masked]>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

On Thu, May 03, 2018 at 08:31:34AM -0700, Tom Haynes wrote:
> >> supposed to describe the format of what you are sending and 
> >> receiving for the sec_label field.
> > 
> > By the way, something Chuck noticed is that the Linux client and 
> > server implementations are completely ignoring the LFS field--they 
> > always discard it when receiving, and set it to 0 when sending.  I 
> > assume we should at least fix them to reject non-zero values for now.
> > 
> > --b.
> 

If there's something else we should be using, we could modify them to send that and reject anything that's not that or zero.

--b.

---

From: Bruce Fields <[email-masked]>
Date: Thu, 3 May 2018 19:59:03 -0400

On Thu, May 03, 2018 at 09:58:30PM +0000, Quigley, David wrote:
> >From an implementation standpoint I don't think this is an issue
> >because what it means currently is the MAC on both the client and
> >server have to match. In the future this could be changed so an
> >intermediate daemon handles the label and policy translation. Ideally
> >an SELinux enabled server could receive a request from a Trusted
> >Solaris (I think its trusted extensions now) and be able to retain
> >the MLS portion of the label and just assign an arbitrary SELinux
> >label. This wasn't implemented or attempted as Linux is the only
> >Labeled NFS implementation at the moment but that was the intent.

Unfortunately the selinux folks don't seem to expect it to work well
even between different versions of RHEL, and that doesn't seem to be a
problem the LFS field can solve:

	https://bugzilla.redhat.com/show_bug.cgi?id=1406885#c14

I'm a little disappointed by that.  Maybe I have the wrong expectations.

--b.