Fwd: New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

Fwd: New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

[Chuck Lever]

> Begin forwarded message:
> 
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
> Date: April 10, 2018 at 8:36:36 AM MDT
> To: "Charles Lever" <chuck.lever@oracle.com>, "Chuck Lever" <chuck.lever@oracle.com>
> 
> 
> A new version of I-D, draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
> has been successfully submitted by Charles Lever and posted to the
> IETF repository.
> 
> Name:		draft-cel-nfsv4-linux-seclabel-xtensions
> Revision:	00
> Title:		Linux-related Extensions to NFS version 4.2 Security Labels
> Document date:	2018-04-09
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-linux-seclabel-xtensions/
> Htmlized:       https://tools.ietf.org/html/draft-cel-nfsv4-linux-seclabel-xtensions-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-linux-seclabel-xtensions
> 
> 
> Abstract:
>   NFS version 4.2 introduces an optional feature known as NFSv4
>   Security Labels.  This document extends NFSv4 Security Labels to
>   support Linux file capabilities and the Linux Integrity Measurement
>   Architecture.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

Initial revision, by no means final. Review comments welcome.

I'm toying with some ideas here. If you find anything controversial
you are welcome to provide input.


--
Chuck Lever

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

[Mimi Zohar]

Hi Chuck,

On Tue, 2018-04-10 at 08:44 -0600, Chuck Lever wrote:
> > Begin forwarded message:
> > 
> > From: internet-drafts@ietf.org
> > Subject: New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
> > Date: April 10, 2018 at 8:36:36 AM MDT
> > To: "Charles Lever" <chuck.lever@oracle.com>, "Chuck Lever" <chuck.lever@oracle.com>
> > 
> > 
> > A new version of I-D, draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
> > has been successfully submitted by Charles Lever and posted to the
> > IETF repository.
> > 
> > Name:		draft-cel-nfsv4-linux-seclabel-xtensions
> > Revision:	00
> > Title:		Linux-related Extensions to NFS version 4.2 Security Labels
> > Document date:	2018-04-09
> > Group:		Individual Submission
> > Pages:		8
> > URL:            https://www.ietf.org/internet-drafts/draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-linux-seclabel-xtensions/
> > Htmlized:       https://tools.ietf.org/html/draft-cel-nfsv4-linux-seclabel-xtensions-00
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-linux-seclabel-xtensions
> > 
> > 
> > Abstract:
> >   NFS version 4.2 introduces an optional feature known as NFSv4
> >   Security Labels.  This document extends NFSv4 Security Labels to
> >   support Linux file capabilities and the Linux Integrity Measurement
> >   Architecture.
> > 

Very nice!  Thank you so much for writing this up.

> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > The IETF Secretariat
> 
> Initial revision, by no means final. Review comments welcome.
> 
> I'm toying with some ideas here. If you find anything controversial
> you are welcome to provide input.

"security.ima" may contain either a file hash or a file signature.
 "security.evm" may contain either an HMAC or a signature of the file
metdata.  Only the security.evm portable and immutable file signature,
not the HMAC which is TPM specific, will be applicable.

The last paragraph of section 1.1 mentions that the private key needs
to be protected, which is fine, but then mentions a TPM.  This might
be a bit confusing in the context of EVM/IMA-appraisal as only the
trusted "master" key, which is used to encrypt/decrypt the EVM key, is
created and decrypted by the TPM.

Mimi

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

[Serge E. Hallyn]

Quoting Mimi Zohar (zohar@linux.vnet.ibm.com):
> Hi Chuck,
> 
> On Tue, 2018-04-10 at 08:44 -0600, Chuck Lever wrote:
> > > Begin forwarded message:
> > > 
> > > From: internet-drafts@ietf.org
> > > Subject: New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
> > > Date: April 10, 2018 at 8:36:36 AM MDT
> > > To: "Charles Lever" <chuck.lever@oracle.com>, "Chuck Lever" <chuck.lever@oracle.com>
> > > 
> > > 
> > > A new version of I-D, draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
> > > has been successfully submitted by Charles Lever and posted to the
> > > IETF repository.
> > > 
> > > Name:		draft-cel-nfsv4-linux-seclabel-xtensions
> > > Revision:	00
> > > Title:		Linux-related Extensions to NFS version 4.2 Security Labels
> > > Document date:	2018-04-09
> > > Group:		Individual Submission
> > > Pages:		8
> > > URL:            https://www.ietf.org/internet-drafts/draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
> > > Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-linux-seclabel-xtensions/
> > > Htmlized:       https://tools.ietf.org/html/draft-cel-nfsv4-linux-seclabel-xtensions-00
> > > Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-linux-seclabel-xtensions
> > > 
> > > 
> > > Abstract:
> > >   NFS version 4.2 introduces an optional feature known as NFSv4
> > >   Security Labels.  This document extends NFSv4 Security Labels to
> > >   support Linux file capabilities and the Linux Integrity Measurement
> > >   Architecture.
> > > 
> 
> Very nice!  Thank you so much for writing this up.

Hi Chuck,

did you have any plans to extend the file capabilities support to
also handle namespaced file capabilities?  Is that orthogonal to
this spec?

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

[Chuck Lever]

Hi Serge-

Apologies for the delay. My e-mail system dropped your reply.
Mimi forwarded it to me today (thanks!). See below.


> On Apr 24, 2018, at 10:58 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> -------- Forwarded Message --------
> From: Serge E. Hallyn <serge@hallyn.com>
> To: Mimi Zohar <zohar@linux.vnet.ibm.com>
> Cc: Chuck Lever <chuck.lever@oracle.com>, linux-integrity@vger.kernel.
> org, Serge E. Hallyn <serge@hallyn.com>, Michael Halcrow <mhalcrow@goo
> gle.com>
> Subject: Re: Fwd: New Version Notification for draft-cel-nfsv4-linux-
> seclabel-xtensions-00.txt
> Date: Thu, 19 Apr 2018 11:32:42 -0500
> 
> Quoting Mimi Zohar (zohar@linux.vnet.ibm.com):
>> Hi Chuck,
>> 
>> On Tue, 2018-04-10 at 08:44 -0600, Chuck Lever wrote:
>>>> Begin forwarded message:
>>>> 
>>>> From: internet-drafts@ietf.org
>>>> Subject: New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
>>>> Date: April 10, 2018 at 8:36:36 AM MDT
>>>> To: "Charles Lever" <chuck.lever@oracle.com>, "Chuck Lever" <chuck.lever@oracle.com>
>>>> 
>>>> 
>>>> A new version of I-D, draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
>>>> has been successfully submitted by Charles Lever and posted to the
>>>> IETF repository.
>>>> 
>>>> Name:		draft-cel-nfsv4-linux-seclabel-xtensions
>>>> Revision:	00
>>>> Title:		Linux-related Extensions to NFS version 4.2 Security Labels
>>>> Document date:	2018-04-09
>>>> Group:		Individual Submission
>>>> Pages:		8
>>>> URL:            https://www.ietf.org/internet-drafts/draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
>>>> Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-linux-seclabel-xtensions/
>>>> Htmlized:       https://tools.ietf.org/html/draft-cel-nfsv4-linux-seclabel-xtensions-00
>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-linux-seclabel-xtensions
>>>> 
>>>> 
>>>> Abstract:
>>>>  NFS version 4.2 introduces an optional feature known as NFSv4
>>>>  Security Labels.  This document extends NFSv4 Security Labels to
>>>>  support Linux file capabilities and the Linux Integrity Measurement
>>>>  Architecture.
>>>> 
>> 
>> Very nice!  Thank you so much for writing this up.
> 
> Hi Chuck,
> 
> did you have any plans to extend the file capabilities support to
> also handle namespaced file capabilities?  Is that orthogonal to
> this spec?

It probably isn't clear to readers who are not familiar with
how the IETF works; that's OK, there have been similar comments
about this document in other forums. Just to be clear, this I-D
is not a design doc for a Linux implementation of either IMA on
NFS, or file capabilities on NFS. It is only about what goes on
the wire. An eventual prototype implementation will help us
understand subtleties and further implementation requirements.

My naive response to your specific question is that namespaces
are objects that exist on Linux NFS clients, thus are not directly
exposed to servers or other clients. Do you have a convenient
description of file capabilities so I can better understand if
the NFS protocol needs to be aware of namespaces?


--
Chuck Lever

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

[Serge E. Hallyn]

Quoting Chuck Lever (chuck.lever@oracle.com):
> Hi Serge-
> 
> Apologies for the delay. My e-mail system dropped your reply.
> Mimi forwarded it to me today (thanks!). See below.

Oh - I hope this one goes through :)

> > On Apr 24, 2018, at 10:58 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
...
> > Hi Chuck,
> > 
> > did you have any plans to extend the file capabilities support to
> > also handle namespaced file capabilities?  Is that orthogonal to
> > this spec?
> 
> It probably isn't clear to readers who are not familiar with
> how the IETF works; that's OK, there have been similar comments
> about this document in other forums. Just to be clear, this I-D
> is not a design doc for a Linux implementation of either IMA on
> NFS, or file capabilities on NFS. It is only about what goes on
> the wire. An eventual prototype implementation will help us
> understand subtleties and further implementation requirements.

Right so the details of how they are namespaced are (I believe) out
of scope not only for the wire protocol but also for the NFS server.
However the V3 capabilities (see below) will need to be able to pass
a "namespaced root ID" along with the capability.  This is to support
serving a filesystem which will be used by a user namespace (usually
meaning "a container") created by the namespace which mounted the NFS
filesystem.

This will allow a host (or a container) to nfs-mount a filesystem
which has files owned by (say) uid 100005, with file capabilities
attached which will only take effect when (say) uid 100000 is mapped to
root in the container.

So root in the container will be able to add cap_net_raw=pe to
/usr/bin/ping, and that capability will take effect only inside the
container, not on the host.  Without this ability, installing/upgrading
fedora/centos fails in user namespaced containers.

> My naive response to your specific question is that namespaces
> are objects that exist on Linux NFS clients, thus are not directly
> exposed to servers or other clients. Do you have a convenient
> description of file capabilities so I can better understand if
> the NFS protocol needs to be aware of namespaces?

The general capabilities.7 and user_namespaces.7 manpages (see
http://man7.org/linux/man-pages/man7/capabilities.7.html
and
http://man7.org/linux/man-pages/man7/user_namespaces.7.html )
give some background - see section 'File capabilities' in
capabilities.7 .  The capabilties.7 update for namespaced file
capabilities is still under discussion - the latest commit is
at
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=6442c03b6815eda1202def03cc1e4eb9a57830f1
with the resulting file at
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man7/capabilities.7?id=6442c03b6815eda1202def03cc1e4eb9a57830f1
(check out maybe starting at line 935), and the email thread is at
http://www.spinics.net/lists/linux-man/msg12492.html

Finally, the original patch description is here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xattr.c?h=v4.17-rc2&id=8db6c34f1dbc8e06aa016a9b829b06902c3e1340

thanks,
-serge

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

[Chuck Lever]

> On Apr 24, 2018, at 1:47 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> 
> Quoting Chuck Lever (chuck.lever@oracle.com):
>> Hi Serge-
>> 
>> Apologies for the delay. My e-mail system dropped your reply.
>> Mimi forwarded it to me today (thanks!). See below.
> 
> Oh - I hope this one goes through :)
> 
>>> On Apr 24, 2018, at 10:58 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> ...
>>> Hi Chuck,
>>> 
>>> did you have any plans to extend the file capabilities support to
>>> also handle namespaced file capabilities?  Is that orthogonal to
>>> this spec?
>> 
>> It probably isn't clear to readers who are not familiar with
>> how the IETF works; that's OK, there have been similar comments
>> about this document in other forums. Just to be clear, this I-D
>> is not a design doc for a Linux implementation of either IMA on
>> NFS, or file capabilities on NFS. It is only about what goes on
>> the wire. An eventual prototype implementation will help us
>> understand subtleties and further implementation requirements.
> 
> Right so the details of how they are namespaced are (I believe) out
> of scope not only for the wire protocol but also for the NFS server.
> However the V3 capabilities (see below) will need to be able to pass
> a "namespaced root ID" along with the capability.  This is to support
> serving a filesystem which will be used by a user namespace (usually
> meaning "a container") created by the namespace which mounted the NFS
> filesystem.
> 
> This will allow a host (or a container) to nfs-mount a filesystem
> which has files owned by (say) uid 100005, with file capabilities
> attached which will only take effect when (say) uid 100000 is mapped to
> root in the container.
> 
> So root in the container will be able to add cap_net_raw=pe to
> /usr/bin/ping, and that capability will take effect only inside the
> container, not on the host.  Without this ability, installing/upgrading
> fedora/centos fails in user namespaced containers.

OK, fair enough.

There is an interoperability concern with how file capabilities
are represented in text format. Currently the I-D does not
specify how this conversion is done, but rather rashly assumes
that all NFS endpoints that claim to support Linux file capabi-
lities will be able to understand that format.

Mostly this is because I don't know of a real citable standard
that describes the text that comes out of cap_to_text(3). A man
page doesn't really count as citable :-)

So if cap_to_text(3) handles namespaces already, then this
should be taken care of transparently. Otherwise, we have to
start thinking carefully about what else will go into the text
strings: versioning, namespace, and so on, and that will have
to be spelled out to some extent in the I-D.


>> My naive response to your specific question is that namespaces
>> are objects that exist on Linux NFS clients, thus are not directly
>> exposed to servers or other clients. Do you have a convenient
>> description of file capabilities so I can better understand if
>> the NFS protocol needs to be aware of namespaces?
> 
> The general capabilities.7 and user_namespaces.7 manpages (see
> http://man7.org/linux/man-pages/man7/capabilities.7.html
> and
> http://man7.org/linux/man-pages/man7/user_namespaces.7.html )
> give some background - see section 'File capabilities' in
> capabilities.7 .  The capabilties.7 update for namespaced file
> capabilities is still under discussion - the latest commit is
> at
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=6442c03b6815eda1202def03cc1e4eb9a57830f1
> with the resulting file at
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man7/capabilities.7?id=6442c03b6815eda1202def03cc1e4eb9a57830f1
> (check out maybe starting at line 935), and the email thread is at
> http://www.spinics.net/lists/linux-man/msg12492.html
> 
> Finally, the original patch description is here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xattr.c?h=v4.17-rc2&id=8db6c34f1dbc8e06aa016a9b829b06902c3e1340
> 
> thanks,
> -serge

--
Chuck Lever

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

[Serge E. Hallyn]

Quoting Chuck Lever (chuck.lever@oracle.com):
> 
> 
> > On Apr 24, 2018, at 1:47 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > 
> > Quoting Chuck Lever (chuck.lever@oracle.com):
> >> Hi Serge-
> >> 
> >> Apologies for the delay. My e-mail system dropped your reply.
> >> Mimi forwarded it to me today (thanks!). See below.
> > 
> > Oh - I hope this one goes through :)
> > 
> >>> On Apr 24, 2018, at 10:58 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > ...
> >>> Hi Chuck,
> >>> 
> >>> did you have any plans to extend the file capabilities support to
> >>> also handle namespaced file capabilities?  Is that orthogonal to
> >>> this spec?
> >> 
> >> It probably isn't clear to readers who are not familiar with
> >> how the IETF works; that's OK, there have been similar comments
> >> about this document in other forums. Just to be clear, this I-D
> >> is not a design doc for a Linux implementation of either IMA on
> >> NFS, or file capabilities on NFS. It is only about what goes on
> >> the wire. An eventual prototype implementation will help us
> >> understand subtleties and further implementation requirements.
> > 
> > Right so the details of how they are namespaced are (I believe) out
> > of scope not only for the wire protocol but also for the NFS server.
> > However the V3 capabilities (see below) will need to be able to pass
> > a "namespaced root ID" along with the capability.  This is to support
> > serving a filesystem which will be used by a user namespace (usually
> > meaning "a container") created by the namespace which mounted the NFS
> > filesystem.
> > 
> > This will allow a host (or a container) to nfs-mount a filesystem
> > which has files owned by (say) uid 100005, with file capabilities
> > attached which will only take effect when (say) uid 100000 is mapped to
> > root in the container.
> > 
> > So root in the container will be able to add cap_net_raw=pe to
> > /usr/bin/ping, and that capability will take effect only inside the
> > container, not on the host.  Without this ability, installing/upgrading
> > fedora/centos fails in user namespaced containers.
> 
> OK, fair enough.
> 
> There is an interoperability concern with how file capabilities
> are represented in text format. Currently the I-D does not
> specify how this conversion is done, but rather rashly assumes
> that all NFS endpoints that claim to support Linux file capabi-
> lities will be able to understand that format.
> 
> Mostly this is because I don't know of a real citable standard
> that describes the text that comes out of cap_to_text(3). A man
> page doesn't really count as citable :-)
> 
> So if cap_to_text(3) handles namespaces already, then this
> should be taken care of transparently. Otherwise, we have to
> start thinking carefully about what else will go into the text
> strings: versioning, namespace, and so on, and that will have
> to be spelled out to some extent in the I-D.

cap_to_text does not, and actually the cap_t itself does not
have a concept of the namespaces either.  That's because for
the most part the kernel transparently does the conversion: if
you want filecaps in a user namespace, you'll generally enter
the user namespace to do the writing.  The one case where it
doesn't is when you are in a parent namespace and want to
immediately write a capability for a namespace with rootid=100000.
In that case right now you need to write the xattr by hand.

It would definately be worth it to update the the libcap api
to handle this.  I'm going to make a long term note to look
into a clean way to do that.

thanks,
Serge