linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: Mimi Zohar <zohar@linux.ibm.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 16:31:31 +0000	[thread overview]
Message-ID: <fcdb168d27214b5e85c3b741f184cde9@huawei.com> (raw)
In-Reply-To: <1589298622.5098.67.camel@linux.ibm.com>

> From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> Sent: Tuesday, May 12, 2020 5:50 PM
> On Tue, 2020-05-12 at 15:31 +0000, Roberto Sassu wrote:
> > > From: owner-linux-security-module@vger.kernel.org [mailto:owner-
> linux-
> > > security-module@vger.kernel.org] On Behalf Of Mimi Zohar
> > > Sent: Tuesday, May 12, 2020 4:17 PM
> > > On Tue, 2020-05-12 at 07:54 +0000, Roberto Sassu wrote:
> > > > > > > Roberto, EVM is only triggered by IMA, unless you've modified
> the
> > > > > > > kernel to do otherwise.
> > > > > >
> > > > > > EVM would deny xattr/attr operations even if IMA is disabled in
> the
> > > > > > kernel configuration. For example, evm_setxattr() returns the
> value
> > > > > > from evm_protect_xattr(). IMA is not involved there.
> > > > >
> > > > > Commit ae1ba1676b88 ("EVM: Allow userland to permit modification
> of
> > > > > EVM-protected metadata")
> > > introduced EVM_ALLOW_METADATA_WRITES
> > > > > to allow writing the EVM portable and immutable file signatures.
> > > >
> > > > According to Documentation/ABI/testing/evm:
> > > >
> > > > Note that once a key has been loaded, it will no longer be
> > > > possible to enable metadata modification.
> > >
> > > Not any key, but the HMAC key.
> > >
> > > 2         Permit modification of EVM-protected metadata at
> > >           runtime. Not supported if HMAC validation and
> > >           creation is enabled.
> >
> > #ifdef CONFIG_EVM_LOAD_X509
> > void __init evm_load_x509(void)
> > {
> > [...]
> >         rc = integrity_load_x509(INTEGRITY_KEYRING_EVM,
> CONFIG_EVM_X509_PATH);
> >         if (!rc)
> >                 evm_initialized |= EVM_INIT_X509;
> >
> >
> > static ssize_t evm_write_key(struct file *file, const char __user *buf,
> >                              size_t count, loff_t *ppos)
> > {
> > [...]
> >         /* Don't allow a request to freshly enable metadata writes if
> >          * keys are loaded.
> >          */
> >         if ((i & EVM_ALLOW_METADATA_WRITES) &&
> >             ((evm_initialized & EVM_KEY_MASK) != 0) &&
> >             !(evm_initialized & EVM_ALLOW_METADATA_WRITES))
> >                 return -EPERM;
> >
> > Should have been:
> >
> >         if ((i & EVM_ALLOW_METADATA_WRITES) &&
> >             ((evm_initialized & EVM_INIT_HMAC) != 0) &&
> >             !(evm_initialized & EVM_ALLOW_METADATA_WRITES))
> >                 return -EPERM;
> 
> Ok
> 
> >
> > > 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.

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli

  reply	other threads:[~2020-05-12 16:31 UTC|newest]

Thread overview: 22+ 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-05-06 16:11 ` [RFC][PATCH 1/3] evm: Move hooks outside LSM infrastructure 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 [this message]
2020-05-12 19:38                               ` Mimi Zohar
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=fcdb168d27214b5e85c3b741f184cde9@huawei.com \
    --to=roberto.sassu@huawei.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=viro@zeniv.linux.org.uk \
    --cc=zohar@linux.ibm.com \
    /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).