On Fri, 2021-06-18 at 12:35 -0400, Paul Moore wrote:

On Fri, Jun 18, 2021 at 12:04 PM Mimi Zohar [off-list ref] wrote:

quoted

On Thu, 2021-06-17 at 23:18 -0400, Paul Moore wrote:

quoted

On Thu, Jun 17, 2021 at 11:28 AM Mimi Zohar [off-list ref] wrote:

quoted

On Thu, 2021-06-17 at 07:09 +0000, Roberto Sassu wrote:

...

quoted

quoted

An alternative would be to do the EVM verification twice if the
first time didn't succeed (with vfs_getxattr_alloc() and with the
new function that behaves like vfs_getxattr()).

Unfortunately, I don't see an alternative.

... and while unfortunate, the impact should be non-existant if you
are using the right tools to label files or ensuring that you are
formatting labels properly if doing it by hand.

Handling a corner case is good, but I wouldn't add a lot of code
complexity trying to optimize it.

From userspace it's really difficult to understand the EVM signature
verification failure is due to the missing NULL.

I would argue that any signature verification failure, regardless of
the mechanism, is hard to understand.  It either passes or it fails,
and if it fails good luck trying to determine what exactly isn't
matching up; especially if you really don't know the Right Value.

In this case, the discussion is about signing and verifying file meta-
data hashes.  With EVM portable and immutable signatures, the file
meta-data is known.  The userspace tool evmct is able to verify the
file meta-data signature, which the kernel rejects.

What I mean by the corner case was the fact that the recommended tools
should always do the right thing with respect to '\0' termination,
this should really only be an issue if someone is winging it and doing
it by hand or with their own tools.

I'm not disagreeing with you.  However, it's still annoying, confusing,
and really frustrating.   That's why we're at least including debugging
information.  In addtion, Roberto will provide the reason.

thanks,

Mimi