From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Matthew Garrett <mjg59@google.com>, linux-integrity@vger.kernel.org
Subject: Re: [PATCH V5 3/3] EVM: Allow runtime modification of the set of verified xattrs
Date: Sun, 13 May 2018 12:41:40 -0400 [thread overview]
Message-ID: <1526229700.3898.26.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180511231236.5501-3-mjg59@google.com>
On Fri, 2018-05-11 at 16:12 -0700, Matthew Garrett wrote:
> Sites may wish to provide additional metadata alongside files in order
> to make more fine-grained security decisions[1]. The security of this is
> enhanced if this metadata is protected, something that EVM makes
> possible. However, the kernel cannot know about the set of extended
> attributes that local admins may wish to protect, and hardcoding this
> policy in the kernel makes it difficult to change over time and less
> convenient for distributions to enable.
>
> This patch adds a new /sys/kernel/security/evm_xattrs node, which can be
> read to obtain the current set of EVM-protected extended attributes or
> written to in order to add new entries. Extending this list will not
> change the validity of any existing signatures provided that the file
> in question does not have any of the additional extended attributes -
> missing xattrs are skipped when calculating the EVM hash.
The new pathname introduced in the new patch needs to be propagated
to the patch description, Documentation and Kconfig in this patch.
>
> [1] For instance, a package manager could install information about the
> package uploader in an additional extended attribute. Local LSM policy
> could then be associated with that extended attribute in order to
> restrict the privileges available to packages from less trusted
> uploaders.
>
> Signed-off-by: Matthew Garrett <mjg59@google.com>
> ---
>
> I think this covers the review comments.
Yes, it looks good. The pathname changes introduced in the new patch,
need to be propagated to the patch description, above, Documentation,
and Kconfig. The only other change is that with the introduction of
requiring the xattr names to be prefixed with "security", locking the
xattr names list fails. After making these tw changes, there's no
need to re-post the entire patch set. Please re-post just this one.
> Documentation/ABI/testing/evm | 13 +++
> include/uapi/linux/audit.h | 1 +
> security/integrity/evm/Kconfig | 11 ++
> security/integrity/evm/evm_crypto.c | 2 +-
> security/integrity/evm/evm_main.c | 6 +-
> security/integrity/evm/evm_secfs.c | 173 ++++++++++++++++++++++++++++
> 6 files changed, 202 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/ABI/testing/evm b/Documentation/ABI/testing/evm
> index d12cb2eae9ee..fa31df7fd30b 100644
> --- a/Documentation/ABI/testing/evm
> +++ b/Documentation/ABI/testing/evm
> @@ -57,3 +57,16 @@ Description:
> dracut (via 97masterkey and 98integrity) and systemd (via
> core/ima-setup) have support for loading keys at boot
> time.
> +
> +What: security/evm_xattrs
Update
> +Date: April 2018
> +Contact: Matthew Garrett <mjg59@google.com>
> +Description:
> + Shows the set of extended attributes used to calculate or
> + validate the EVM signature, and allows additional attributes
> + to be added at runtime. Any signatures generated after
> + additional attributes are added (and on files posessing those
> + additional attributes) will only be valid if the same
> + additional attributes are configured on system boot. Writing
> + a single period (.) will lock the xattr list from any further
> + modification.
Writing '.', doesn't match the code.
> +config EVM_ADD_XATTRS
> + bool "Add additional EVM extended attributes at runtime"
> + depends on EVM
> + default n
> + help
> + Allow userland to provide additional xattrs for HMAC calculation.
> +
> + When this option is enabled, root can add additional xattrs to the
> + list used by EVM by writing them into
> + /sys/kernel/security/evm_xattrs.
Update
> +
> + if (strcmp(xattr->name, ".") == 0) {
> + evm_xattrs_locked = 1;
> + inode = evm_xattrs->d_inode;
> + inode_lock(inode);
> + newattrs.ia_mode = S_IFREG | 0440;
> + newattrs.ia_valid = ATTR_MODE;
> + err = notify_change(evm_xattrs, &newattrs, NULL);
> + inode_unlock(inode);
> + audit_log_format(ab, "locked");
> + if (!err)
> + err = count;
> + goto out;
> + }
> +
> + audit_log_format(ab, "xattr=");
> + audit_log_untrustedstring(ab, xattr->name);
> +
> + if (strncmp(xattr->name, XATTR_SECURITY_PREFIX,
> + XATTR_SECURITY_PREFIX_LEN) != 0) {
> + err = -EINVAL;
> + goto out;
> + }
This test now prevents locking the xattr names list. Making this an
else clause will fix it.
thanks,
Mimi
next prev parent reply other threads:[~2018-05-13 16:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-11 23:12 [PATCH V5 1/3] integrity: Add an integrity directory in securityfs Matthew Garrett
2018-05-11 23:12 ` [PATCH V5 2/3] EVM: turn evm_config_xattrnames into a list Matthew Garrett
2018-05-11 23:12 ` [PATCH V5 3/3] EVM: Allow runtime modification of the set of verified xattrs Matthew Garrett
2018-05-13 16:41 ` Mimi Zohar [this message]
2018-05-14 17:01 ` Matthew Garrett
2018-05-14 17:19 ` Mimi Zohar
2018-05-14 17:35 ` Mimi Zohar
2018-05-14 17:36 ` Matthew Garrett
2018-05-14 18:50 ` Matthew Garrett
2018-05-14 21:02 ` Mimi Zohar
2018-05-14 23:12 ` Matthew Garrett
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=1526229700.3898.26.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=mjg59@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.