From: Mimi Zohar <zohar@linux.ibm.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Roberto Sassu <roberto.sassu@huawei.com>,
Stefan Berger <stefanb@linux.ibm.com>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"stephen.smalley.work@gmail.com" <stephen.smalley.work@gmail.com>,
"casey@schaufler-ca.com" <casey@schaufler-ca.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"selinux@vger.kernel.org" <selinux@vger.kernel.org>
Subject: Re: [PATCH] fs: Return raw xattr for security.* if there is size disagreement with LSMs
Date: Fri, 18 Jun 2021 13:22:07 -0400 [thread overview]
Message-ID: <2a57faec7fcc69cc1ae6939930adafa5eb164e0c.camel@linux.ibm.com> (raw)
In-Reply-To: <CAHC9VhRb_Xg11c-qhQUY_KPf6dyHn06NYACigjN4ee+p8NtB6A@mail.gmail.com>
On Fri, 2021-06-18 at 12:35 -0400, Paul Moore wrote:
> On Fri, Jun 18, 2021 at 12:04 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Thu, 2021-06-17 at 23:18 -0400, Paul Moore wrote:
> > > On Thu, Jun 17, 2021 at 11:28 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Thu, 2021-06-17 at 07:09 +0000, Roberto Sassu wrote:
> > >
> > > ...
> > >
> > > > > 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
prev parent reply other threads:[~2021-06-18 17:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-11 9:44 Size mismatch between vfs_getxattr_alloc() and vfs_getxattr() Roberto Sassu
2021-06-16 13:22 ` [PATCH] fs: Return raw xattr for security.* if there is size disagreement with LSMs Roberto Sassu
2021-06-16 14:40 ` Stefan Berger
2021-06-17 7:09 ` Roberto Sassu
2021-06-17 15:27 ` Mimi Zohar
2021-06-17 16:05 ` Roberto Sassu
2021-06-18 3:18 ` Paul Moore
2021-06-18 16:04 ` Mimi Zohar
2021-06-18 16:10 ` Roberto Sassu
2021-06-18 16:35 ` Paul Moore
2021-06-18 17:22 ` Mimi Zohar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2a57faec7fcc69cc1ae6939930adafa5eb164e0c.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=casey@schaufler-ca.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=selinux@vger.kernel.org \
--cc=stefanb@linux.ibm.com \
--cc=stephen.smalley.work@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).