From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
Stefan Berger <stefanb@linux.ibm.com>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"paul@paul-moore.com" <paul@paul-moore.com>,
"stephen.smalley.work@gmail.com" <stephen.smalley.work@gmail.com>,
"casey@schaufler-ca.com" <casey@schaufler-ca.com>
Cc: "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: Thu, 17 Jun 2021 11:27:59 -0400 [thread overview]
Message-ID: <d822efcc0bb05178057ab2f52293575124cde1fc.camel@linux.ibm.com> (raw)
In-Reply-To: <9cb676de40714d0288f85292c1f1a430@huawei.com>
On Thu, 2021-06-17 at 07:09 +0000, Roberto Sassu wrote:
> > From: Stefan Berger [mailto:stefanb@linux.ibm.com]
> > Sent: Wednesday, June 16, 2021 4:40 PM
> > On 6/16/21 9:22 AM, Roberto Sassu wrote:
> > > vfs_getxattr() differs from vfs_setxattr() in the way it obtains the xattr
> > > value. The former gives precedence to the LSMs, and if the LSMs don't
> > > provide a value, obtains it from the filesystem handler. The latter does
> > > the opposite, first invokes the filesystem handler, and if the filesystem
> > > does not support xattrs, passes the xattr value to the LSMs.
> > >
> > > The problem is that not necessarily the user gets the same xattr value that
> > > he set. For example, if he sets security.selinux with a value not
> > > terminated with '\0', he gets a value terminated with '\0' because SELinux
> > > adds it during the translation from xattr to internal representation
> > > (vfs_setxattr()) and from internal representation to xattr
> > > (vfs_getxattr()).
> > >
> > > Normally, this does not have an impact unless the integrity of xattrs is
> > > verified with EVM. The kernel and the user see different values due to the
> > > different functions used to obtain them:
> > >
> > > kernel (EVM): uses vfs_getxattr_alloc() which obtains the xattr value from
> > > the filesystem handler (raw value);
> > >
> > > user (ima-evm-utils): uses vfs_getxattr() which obtains the xattr value
> > > from the LSMs (normalized value).
> >
> > Maybe there should be another implementation similar to
> > vfs_getxattr_alloc() (or modify it) to behave like vfs_getxattr() but do
> > the memory allocation part so that the kernel sees what user space see
> > rather than modifying it with your patch so that user space now sees
> > something different than what it has been for years (previous
> > NUL-terminated SELinux xattr may not be NUL-terminated anymore)?
>
> I'm concerned that this would break HMACs/digital signatures
> calculated with raw values.
Which would happen if the LSM is not enabled (e.g. "lsm=" boot command
line option).
>
> 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.
thanks,
Mimi
next prev parent reply other threads:[~2021-06-17 15:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ee75bde9a17f418984186caa70abd33b@huawei.com>
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 [this message]
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
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=d822efcc0bb05178057ab2f52293575124cde1fc.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).