linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
	"david.safford@gmail.com" <david.safford@gmail.com>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"jmorris@namei.org" <jmorris@namei.org>,
	John Johansen <john.johansen@canonical.com>,
	"matthewgarrett@google.com" <matthewgarrett@google.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>,
	Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>
Subject: Re: [RFC][PATCH 1/3] evm: Move hooks outside LSM infrastructure
Date: Tue, 12 May 2020 15:38:01 -0400	[thread overview]
Message-ID: <1589312281.5098.91.camel@linux.ibm.com> (raw)
In-Reply-To: <fcdb168d27214b5e85c3b741f184cde9@huawei.com>

On Tue, 2020-05-12 at 16:31 +0000, Roberto Sassu wrote:
> > From: Mimi Zohar [mailto:zohar@linux.ibm.com]

> > > > Each time the EVM protected file metadata is updated, the EVM HMAC
> > is
> > > > updated, assuming the existing EVM HMAC is valid.  Userspace should
> > > > not have access to the HMAC key, so we only allow writing EVM
> > > > signatures.
> > > >
> > > > The only difference between writing the original EVM signature and the
> > > > new portable and immutable signature is the security.ima xattr
> > > > requirement.  Since the new EVM signature does not include the
> > > > filesystem specific data, something else needs to bind the file
> > > > metadata to the file data.  Thus the IMA xattr requirement.
> > > >
> > > > Assuming that the new EVM signature is written last, as long as there
> > > > is an IMA xattr, there shouldn't be a problem writing the new EVM
> > > > signature.
> > >
> > >         /* first need to know the sig type */
> > >         rc = vfs_getxattr_alloc(dentry, XATTR_NAME_EVM, (char
> > **)&xattr_data, 0,
> > >                                 GFP_NOFS);
> > >         if (rc <= 0) {
> > >                 evm_status = INTEGRITY_FAIL;
> > >                 if (rc == -ENODATA) {
> > >                         rc = evm_find_protected_xattrs(dentry);
> > >                         if (rc > 0)
> > >                                 evm_status = INTEGRITY_NOLABEL;
> > >                         else if (rc == 0)
> > >                                 evm_status = INTEGRITY_NOXATTRS; /* new file */
> > >
> > > If EVM_ALLOW_METADATA_WRITES is cleared, only the first xattr
> > > can be written (status INTEGRITY_NOXATTRS is ok). After,
> > > evm_find_protected_xattrs() returns rc > 0, so the status is
> > > INTEGRITY_NOLABEL, which is not ignored by evm_protect_xattr().
> > 
> > With EVM HMAC enabled, as a result of writing the first protected
> > xattr, an EVM HMAC should be calculated and written in
> > evm_inode_post_setxattr().
> 
> To solve the ordering issue, wouldn't allowing setxattr() on a file
> with portable signature that does not yet pass verification be safe?
> evm_update_evmxattr() checks if the signature is portable and
> if yes, does not calculate the HMAC.

Before agreeing to allowing the protected xattrs to be written on a
file with a portable signature that does not yet pass verification are
safe, would we be introducing any new types of attacks?

For example, would we differentiate between portable signatures that
don't pass verification and ones that do?  If we don't differentiate,
could it be used for DoS?  Should it be limited to new files?

Mimi

  reply	other threads:[~2020-05-12 19:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29  7:39 [RFC][PATCH 1/3] evm: Move hooks outside LSM infrastructure Roberto Sassu
2020-04-29  7:39 ` [RFC][PATCH 2/3] evm: Extend API of post hooks to pass the result of pre hooks Roberto Sassu
2020-04-29  7:39 ` [RFC][PATCH 3/3] evm: Return -EAGAIN to ignore verification failures Roberto Sassu
2020-04-30 16:11 ` [RFC][PATCH 1/3] evm: Move hooks outside LSM infrastructure Lev R. Oshvang .
2020-05-01  6:56   ` Roberto Sassu
2020-05-06 16:11 ` Roberto Sassu
2020-05-06 19:44 ` Mimi Zohar
2020-05-06 21:10   ` Mimi Zohar
2020-05-07  7:53     ` Roberto Sassu
2020-05-07 15:17       ` Mimi Zohar
2020-05-07 16:47         ` Roberto Sassu
2020-05-07 20:45           ` Mimi Zohar
2020-05-08 10:20             ` Roberto Sassu
2020-05-08 17:08               ` Mimi Zohar
2020-05-11 14:13                 ` Roberto Sassu
2020-05-11 21:36                   ` Mimi Zohar
2020-05-12  7:54                     ` Roberto Sassu
2020-05-12 14:17                       ` Mimi Zohar
2020-05-12 15:31                         ` Roberto Sassu
2020-05-12 15:50                           ` Mimi Zohar
2020-05-12 16:31                             ` Roberto Sassu
2020-05-12 19:38                               ` Mimi Zohar [this message]
2020-05-13  7:21                                 ` Roberto Sassu
2020-05-13 15:09                                   ` 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=1589312281.5098.91.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=Silviu.Vlasceanu@huawei.com \
    --cc=david.safford@gmail.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.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=matthewgarrett@google.com \
    --cc=roberto.sassu@huawei.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).