CAP_SYS_ADMIN requirement for updating IMA metadata

CAP_SYS_ADMIN requirement for updating IMA metadata

[Chuck Lever]

Hi Mimi-

I'm working on a section of draft-ietf-nfsv4-integrity-measurement that
discusses what kind of access permission is necessary to update a file's
IMA metadata. This is needed because every NFS operation has an associated
user ID -- an NFS server implementer needs to know which users are allowed
to alter the IMA metadata.

On Linux, because the metadata is stored in "security.ima", CAP_SYS_ADMIN
is required.

But on other NFS server implementations (ones that might not have a
capabilities system), IMA metadata could be stored via a mechanism that
does not require any special permission.

And, it seems to me that if a user can alter the file content, there is
no additional harm in her being allowed to update the IMA metadata.

Is there an architectural reason, other than that Linux stores IMA metadata
in a security.* xattr, for requiring a superuser privilege to update IMA
metadata?

Thanks in advance for any insight!


--
Chuck Lever

Re: CAP_SYS_ADMIN requirement for updating IMA metadata

[Mimi Zohar]

On Wed, 2019-05-22 at 10:54 -0400, Chuck Lever wrote:
> Hi Mimi-
> 
> I'm working on a section of draft-ietf-nfsv4-integrity-measurement that
> discusses what kind of access permission is necessary to update a file's
> IMA metadata. This is needed because every NFS operation has an associated
> user ID -- an NFS server implementer needs to know which users are allowed
> to alter the IMA metadata.
> 
> On Linux, because the metadata is stored in "security.ima", CAP_SYS_ADMIN
> is required.
> 
> But on other NFS server implementations (ones that might not have a
> capabilities system), IMA metadata could be stored via a mechanism that
> does not require any special permission.
> 
> And, it seems to me that if a user can alter the file content, there is
> no additional harm in her being allowed to update the IMA metadata.
> 
> Is there an architectural reason, other than that Linux stores IMA metadata
> in a security.* xattr, for requiring a superuser privilege to update IMA
> metadata?

security.ima may contain either a file hash or signature.   The file
hash should be protected via security.evm.[1]  Allowing anyone to
update the file hash would defeat its purpose.

Mimi

[1] Refer to Roberto's proposed change "[PATCH 3/4] ima: don't ignore
INTEGRITY_UNKNOWN EVM status"

Re: CAP_SYS_ADMIN requirement for updating IMA metadata

[Chuck Lever]

> On May 22, 2019, at 11:19 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Wed, 2019-05-22 at 10:54 -0400, Chuck Lever wrote:
>> Hi Mimi-
>> 
>> I'm working on a section of draft-ietf-nfsv4-integrity-measurement that
>> discusses what kind of access permission is necessary to update a file's
>> IMA metadata. This is needed because every NFS operation has an associated
>> user ID -- an NFS server implementer needs to know which users are allowed
>> to alter the IMA metadata.
>> 
>> On Linux, because the metadata is stored in "security.ima", CAP_SYS_ADMIN
>> is required.
>> 
>> But on other NFS server implementations (ones that might not have a
>> capabilities system), IMA metadata could be stored via a mechanism that
>> does not require any special permission.
>> 
>> And, it seems to me that if a user can alter the file content, there is
>> no additional harm in her being allowed to update the IMA metadata.
>> 
>> Is there an architectural reason, other than that Linux stores IMA metadata
>> in a security.* xattr, for requiring a superuser privilege to update IMA
>> metadata?
> 
> security.ima may contain either a file hash or signature.   The file
> hash should be protected via security.evm.[1]  Allowing anyone to
> update the file hash would defeat its purpose.

I wasn't thinking that anyone would be allowed to update the hash, but
rather that a typical non-Linux NFS server might allow the file's owner
to update it, for example, since it might store IMA metadata via a
mechanism that does not require privilege.

If privilege is a requirement, then the draft has to state it and a non-
Linux NFS server implementation itself will have to enforce the privilege
requirement explicitly. (For Linux that is done by the VFS's xattr code,
not by the NFS server implementation).

I need to understand this better so I can write it up in the draft.
Can you further explain what "defeat its purpose" means?

- If the hash is altered, the effect is the same as if the file content
is altered.

- If the hash is altered, security.evm (which is not exposed via NFS)
would allow a local (non-NFS) accessor to notice the specific problem.

Seems like the file content is protected in these cases even if the
hash is altered arbitrarily. ie, unwanted alteration is detected and
then someone has to restore the file content and hash.

What am I missing?


> Mimi
> 
> [1] Refer to Roberto's proposed change "[PATCH 3/4] ima: don't ignore
> INTEGRITY_UNKNOWN EVM status"

Hm. I didn't entirely understand the patch description. Even so, what
concerns me is that EVM metadata is not exposed to NFS clients in the
current Linux NFS implementation. For NFS, then, either:

- a Linux server (or any server that has a local IMA implementation)
will have to validate an unsigned hash locally, and then the underlying
network transport will have to guarantee hash integrity during transit
via GSS krb5i, for example

or

- the the IMA metadata (here I mean what is stored in security.ima)
will have to be cryptographically signed such that the signature
is also stored in that metadata and not in security.evm so that it
is visible to NFS clients

Currently the draft assumes that the only deployment mode with NFS
will be the latter option.


--
Chuck Lever

Re: CAP_SYS_ADMIN requirement for updating IMA metadata

[Mimi Zohar]

On Wed, 2019-05-22 at 11:49 -0400, Chuck Lever wrote:
> 
> > On May 22, 2019, at 11:19 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Wed, 2019-05-22 at 10:54 -0400, Chuck Lever wrote:
> >> Hi Mimi-
> >> 
> >> I'm working on a section of draft-ietf-nfsv4-integrity-measurement that
> >> discusses what kind of access permission is necessary to update a file's
> >> IMA metadata. This is needed because every NFS operation has an associated
> >> user ID -- an NFS server implementer needs to know which users are allowed
> >> to alter the IMA metadata.
> >> 
> >> On Linux, because the metadata is stored in "security.ima", CAP_SYS_ADMIN
> >> is required.
> >> 
> >> But on other NFS server implementations (ones that might not have a
> >> capabilities system), IMA metadata could be stored via a mechanism that
> >> does not require any special permission.
> >> 
> >> And, it seems to me that if a user can alter the file content, there is
> >> no additional harm in her being allowed to update the IMA metadata.
> >> 
> >> Is there an architectural reason, other than that Linux stores IMA metadata
> >> in a security.* xattr, for requiring a superuser privilege to update IMA
> >> metadata?
> > 
> > security.ima may contain either a file hash or signature.   The file
> > hash should be protected via security.evm.[1]  Allowing anyone to
> > update the file hash would defeat its purpose.
> 
> I wasn't thinking that anyone would be allowed to update the hash, but
> rather that a typical non-Linux NFS server might allow the file's owner
> to update it, for example, since it might store IMA metadata via a
> mechanism that does not require privilege.
> 
> If privilege is a requirement, then the draft has to state it and a non-
> Linux NFS server implementation itself will have to enforce the privilege
> requirement explicitly. (For Linux that is done by the VFS's xattr code,
> not by the NFS server implementation).
> 
> I need to understand this better so I can write it up in the draft.
> Can you further explain what "defeat its purpose" means?
> 
> - If the hash is altered, the effect is the same as if the file content
> is altered.
> 
> - If the hash is altered, security.evm (which is not exposed via NFS)
> would allow a local (non-NFS) accessor to notice the specific problem.
> 
> Seems like the file content is protected in these cases even if the
> hash is altered arbitrarily. ie, unwanted alteration is detected and
> then someone has to restore the file content and hash.
> 
> What am I missing?

Updating security.ima, or for that matter any other EVM protected
security xattrs/file metadata, causes the security.evm HMAC to be
recalculated and written, unless security.evm is a portable &
immutable signature.  To prevent against including other untrusted
modifications from being included in the EVM HMAC, EVM first verifies
the existing security.evm xattr is valid, before recalculating the
HMAC and writing security.evm.

The current design assumes that the file metadata would be included
with the file data and distributed in software packages.  The package
installer is privileged and would install both the file data and
metadata.

In terms of writing security.ima, a similar problem exists in
containers, when root in the container is not the system root.  For
NFS, in addition to the issue of security xattrs, we need to limit the
permitted security.ima types.

Mimi

Re: CAP_SYS_ADMIN requirement for updating IMA metadata

[Chuck Lever]

> On May 23, 2019, at 9:25 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Wed, 2019-05-22 at 11:49 -0400, Chuck Lever wrote:
>> 
>>> On May 22, 2019, at 11:19 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>> 
>>> On Wed, 2019-05-22 at 10:54 -0400, Chuck Lever wrote:
>>>> Hi Mimi-
>>>> 
>>>> I'm working on a section of draft-ietf-nfsv4-integrity-measurement that
>>>> discusses what kind of access permission is necessary to update a file's
>>>> IMA metadata. This is needed because every NFS operation has an associated
>>>> user ID -- an NFS server implementer needs to know which users are allowed
>>>> to alter the IMA metadata.
>>>> 
>>>> On Linux, because the metadata is stored in "security.ima", CAP_SYS_ADMIN
>>>> is required.
>>>> 
>>>> But on other NFS server implementations (ones that might not have a
>>>> capabilities system), IMA metadata could be stored via a mechanism that
>>>> does not require any special permission.
>>>> 
>>>> And, it seems to me that if a user can alter the file content, there is
>>>> no additional harm in her being allowed to update the IMA metadata.
>>>> 
>>>> Is there an architectural reason, other than that Linux stores IMA metadata
>>>> in a security.* xattr, for requiring a superuser privilege to update IMA
>>>> metadata?
>>> 
>>> security.ima may contain either a file hash or signature.   The file
>>> hash should be protected via security.evm.[1]  Allowing anyone to
>>> update the file hash would defeat its purpose.
>> 
>> I wasn't thinking that anyone would be allowed to update the hash, but
>> rather that a typical non-Linux NFS server might allow the file's owner
>> to update it, for example, since it might store IMA metadata via a
>> mechanism that does not require privilege.
>> 
>> If privilege is a requirement, then the draft has to state it and a non-
>> Linux NFS server implementation itself will have to enforce the privilege
>> requirement explicitly. (For Linux that is done by the VFS's xattr code,
>> not by the NFS server implementation).

Thinking this through some more. Here's a common usage scenario.

Suppose we have a NetApp filer that serves a small community of NFS
clients. Suppose the filer can store IMA metadata using the NFS extension
I describe in draft-ietf-nfsv4-integrity-measurement. But note some
things about this NFS server:

 o There is no user execution environment on that server. The only way
that file content is accessed is via NFS.

 o The server does not have any native support for IMA metadata. It
just stores the metadata blob, and does not otherwise interpret it.

 o There is no secondary (EVM) protection of the IMA metadata.

In a software distribution scenario with an NFS server that does not
allow local (non-NFS) access to file contents, the clients must store
the file content and IMA metadata.

Each NFS operation sent by any NFS client has a user ID associated with
it, including operations to store and retrieve IMA metadata. Obviously,
retrieving IMA metadata can be done by anyone on any client that is
allowed to access the server's exports.

Typically the client passes update requests to the NFS server, which
is the final authority on when file content can be modified. The
question is, how does the server determine which clients and users
are allowed to modify IMA metadata?

Assuming a client is simply running some kind of package tool to
install files on an NFS mount, there is no local signing key, so there
is no issue about the writing user requiring a privilege to sign
these file's IMA metadata. The metadata already exists.

The server could authorize IMA metadata changes by user ID, or it could
allow only one of the clients to change IMA metadata. Another possibility
is to allow the file's ACL to determine who can update the metadata.

What is most comparable to local access controls?

My server prototype allows only the root user to update IMA metadata, on
any client that has write access to the export (controlled by /etc/exports).


>> I need to understand this better so I can write it up in the draft.
>> Can you further explain what "defeat its purpose" means?
>> 
>> - If the hash is altered, the effect is the same as if the file content
>> is altered.
>> 
>> - If the hash is altered, security.evm (which is not exposed via NFS)
>> would allow a local (non-NFS) accessor to notice the specific problem.
>> 
>> Seems like the file content is protected in these cases even if the
>> hash is altered arbitrarily. ie, unwanted alteration is detected and
>> then someone has to restore the file content and hash.
>> 
>> What am I missing?
> 
> Updating security.ima, or for that matter any other EVM protected
> security xattrs/file metadata, causes the security.evm HMAC to be
> recalculated and written, unless security.evm is a portable &
> immutable signature.  To prevent against including other untrusted
> modifications from being included in the EVM HMAC, EVM first verifies
> the existing security.evm xattr is valid, before recalculating the
> HMAC and writing security.evm.
> 
> The current design assumes that the file metadata would be included
> with the file data and distributed in software packages.  The package
> installer is privileged and would install both the file data and
> metadata.
> 
> In terms of writing security.ima, a similar problem exists in
> containers, when root in the container is not the system root.  For
> NFS, in addition to the issue of security xattrs, we need to limit the
> permitted security.ima types.
> 
> Mimi

--
Chuck Lever

Re: CAP_SYS_ADMIN requirement for updating IMA metadata

[Mimi Zohar]

[Cc'ing Roberto, Matthew for comment]

On Thu, 2019-05-30 at 13:34 -0400, Chuck Lever wrote:
> 
> > On May 23, 2019, at 9:25 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Wed, 2019-05-22 at 11:49 -0400, Chuck Lever wrote:
> >> 
> >>> On May 22, 2019, at 11:19 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>> 
> >>> On Wed, 2019-05-22 at 10:54 -0400, Chuck Lever wrote:
> >>>> Hi Mimi-
> >>>> 
> >>>> I'm working on a section of draft-ietf-nfsv4-integrity-measurement that
> >>>> discusses what kind of access permission is necessary to update a file's
> >>>> IMA metadata. This is needed because every NFS operation has an associated
> >>>> user ID -- an NFS server implementer needs to know which users are allowed
> >>>> to alter the IMA metadata.
> >>>> 
> >>>> On Linux, because the metadata is stored in "security.ima", CAP_SYS_ADMIN
> >>>> is required.
> >>>> 
> >>>> But on other NFS server implementations (ones that might not have a
> >>>> capabilities system), IMA metadata could be stored via a mechanism that
> >>>> does not require any special permission.
> >>>> 
> >>>> And, it seems to me that if a user can alter the file content, there is
> >>>> no additional harm in her being allowed to update the IMA metadata.
> >>>> 
> >>>> Is there an architectural reason, other than that Linux stores IMA metadata
> >>>> in a security.* xattr, for requiring a superuser privilege to update IMA
> >>>> metadata?
> >>> 
> >>> security.ima may contain either a file hash or signature.   The file
> >>> hash should be protected via security.evm.[1]  Allowing anyone to
> >>> update the file hash would defeat its purpose.
> >> 
> >> I wasn't thinking that anyone would be allowed to update the hash, but
> >> rather that a typical non-Linux NFS server might allow the file's owner
> >> to update it, for example, since it might store IMA metadata via a
> >> mechanism that does not require privilege.
> >> 
> >> If privilege is a requirement, then the draft has to state it and a non-
> >> Linux NFS server implementation itself will have to enforce the privilege
> >> requirement explicitly. (For Linux that is done by the VFS's xattr code,
> >> not by the NFS server implementation).
> 
> Thinking this through some more. Here's a common usage scenario.
> 
> Suppose we have a NetApp filer that serves a small community of NFS
> clients. Suppose the filer can store IMA metadata using the NFS extension
> I describe in draft-ietf-nfsv4-integrity-measurement. But note some
> things about this NFS server:
> 
>  o There is no user execution environment on that server. The only way
> that file content is accessed is via NFS.
> 
>  o The server does not have any native support for IMA metadata. It
> just stores the metadata blob, and does not otherwise interpret it.
> 
>  o There is no secondary (EVM) protection of the IMA metadata.
> 
> In a software distribution scenario with an NFS server that does not
> allow local (non-NFS) access to file contents, the clients must store
> the file content and IMA metadata.
> 
> Each NFS operation sent by any NFS client has a user ID associated with
> it, including operations to store and retrieve IMA metadata. Obviously,
> retrieving IMA metadata can be done by anyone on any client that is
> allowed to access the server's exports.
> 
> Typically the client passes update requests to the NFS server, which
> is the final authority on when file content can be modified. The
> question is, how does the server determine which clients and users
> are allowed to modify IMA metadata?
> 
> Assuming a client is simply running some kind of package tool to
> install files on an NFS mount, there is no local signing key, so there
> is no issue about the writing user requiring a privilege to sign
> these file's IMA metadata. The metadata already exists.
> 
> The server could authorize IMA metadata changes by user ID, or it could
> allow only one of the clients to change IMA metadata. Another possibility
> is to allow the file's ACL to determine who can update the metadata.
> 
> What is most comparable to local access controls?
> 
> My server prototype allows only the root user to update IMA metadata, on
> any client that has write access to the export (controlled by /etc/exports).

It's kind of ironic that Roberto's patch is requiring EVM, well only
for mutable files, while your scenario doesn't support EVM.  I agree
with you that if you have permission to write the file data, that you
should also have permission to write the file metadata.  Since you're
not interested in supporting EVM and are only interested in supporting
signed files, this makes it a lot easier.  IMA could be extended to
allow the file metadata be stored in xattr namespaces other than
security, based on policy.

Mimi

> 
> >> I need to understand this better so I can write it up in the draft.
> >> Can you further explain what "defeat its purpose" means?
> >> 
> >> - If the hash is altered, the effect is the same as if the file content
> >> is altered.
> >> 
> >> - If the hash is altered, security.evm (which is not exposed via NFS)
> >> would allow a local (non-NFS) accessor to notice the specific problem.
> >> 
> >> Seems like the file content is protected in these cases even if the
> >> hash is altered arbitrarily. ie, unwanted alteration is detected and
> >> then someone has to restore the file content and hash.
> >> 
> >> What am I missing?
> > 
> > Updating security.ima, or for that matter any other EVM protected
> > security xattrs/file metadata, causes the security.evm HMAC to be
> > recalculated and written, unless security.evm is a portable &
> > immutable signature.  To prevent against including other untrusted
> > modifications from being included in the EVM HMAC, EVM first verifies
> > the existing security.evm xattr is valid, before recalculating the
> > HMAC and writing security.evm.
> > 
> > The current design assumes that the file metadata would be included
> > with the file data and distributed in software packages.  The package
> > installer is privileged and would install both the file data and
> > metadata.
> > 
> > In terms of writing security.ima, a similar problem exists in
> > containers, when root in the container is not the system root.  For
> > NFS, in addition to the issue of security xattrs, we need to limit the
> > permitted security.ima types.
> > 
> > Mimi
> 
> --
> Chuck Lever
> 
> 
>