All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Matthew Garrett <mjg59@google.com>
Cc: linux-integrity <linux-integrity@vger.kernel.org>
Subject: Re: [PATCH V3 2/2] EVM: Allow runtime modification of the set of verified xattrs
Date: Wed, 09 May 2018 11:00:05 -0400	[thread overview]
Message-ID: <1525878005.3551.223.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CACdnJusHQvBk3rO1DqOr=XyeKZkmFqq+HM9HUO7whvUVG9yxYw@mail.gmail.com>

On Tue, 2018-05-08 at 22:51 +0000, Matthew Garrett wrote:
> On Tue, May 8, 2018 at 2:43 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > On Tue, 2018-05-08 at 21:30 +0000, Matthew Garrett wrote:
> > > As far as I can tell the VFS doesn't do that, and I wouldn't put it past
> > > someone to use UTF-8 at some point...
> 
> > The audit subsystem uses audit_log_untrustedstrings() to check for
> > control characters.  I'm not sure what should be included, but not
> > checking userspace strings doesn't sound right.
> 
> As far as I can tell it's legitimate for xattr names to include control
> characters. I can't think of /why/ someone would do that, but...
> 
> > > I think a config option would make sense here. Locking doesn't seem
> > > unreasonable, but I'm not sure what the threat model would really be -
> > > adding new xattrs would only result in additional signatures validating
> if
> > > they were signed with a trusted key in the first place.
> 
> > Remember adding additional EVM xattrs isn't limited to just EVM
> > signatures, but for the original EVM HMAC as well.  Did you want to
> > limit it to the EVM portable & immutable signatures?
> 
> If you add entries and then signatures are created you'll end up with
> signatures that won't validate on next boot until the same attributes are
> added. That feels at worst like root being able to trigger a DoS, which
> they'd be able to do by tampering with the signatures via the raw device
> node anyway.

With a system with EVM HMAC enabled and an "ima_policy=appraise_tcb"
policy, which appraises all executables and files owned by root, any
new xattrs would cause the EVM HMAC to be recalculated immediately.
 On boot, if any of these files are accessed prior to the additional
xattrs are added, it could cause the system not to boot properly.

True in both cases it is a DoS, but there is a difference between
accessing the raw device and normal usage.

Adding support for additional xattr names is fine.  Making it a
Kconfig option is required.  Being able to lock adding additional
 xattr names should also be required.

Mimi

  reply	other threads:[~2018-05-09 15:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-01 17:51 [PATCH V3 1/2] EVM: turn evm_config_xattrnames into a list Matthew Garrett
2018-05-01 17:51 ` [PATCH V3 2/2] EVM: Allow runtime modification of the set of verified xattrs Matthew Garrett
2018-05-03  3:17   ` Mimi Zohar
2018-05-08 21:30     ` Matthew Garrett
2018-05-08 21:43       ` Mimi Zohar
2018-05-08 22:51         ` Matthew Garrett
2018-05-09 15:00           ` Mimi Zohar [this message]
2018-05-09 17:40             ` Matthew Garrett
2018-05-03  2:48 ` [PATCH V3 1/2] EVM: turn evm_config_xattrnames into a list Mimi Zohar
  -- strict thread matches above, loose matches on Subject: below --
2018-05-08 22:41 Matthew Garrett
2018-05-08 22:41 ` [PATCH V3 2/2] EVM: Allow runtime modification of the set of verified xattrs 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=1525878005.3551.223.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.