From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Matthew Garrett <mjg59@google.com>
Cc: linux-integrity <linux-integrity@vger.kernel.org>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Subject: Re: Writing out EVM protected xattrs while EVM is active
Date: Wed, 18 Oct 2017 14:19:43 -0400 [thread overview]
Message-ID: <1508350783.4510.22.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CACdnJutON0tX5NV_Di1PEOFHN5Hf-E-shQ=Fzv6CSYkkBk-i=Q@mail.gmail.com>
On Wed, 2017-10-18 at 11:08 -0700, Matthew Garrett wrote:
> On Wed, Oct 18, 2017 at 10:51 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> >> Ok. I'm not sure this is easily fixable to handle my use-case without
> >> breaking assumptions made in yours, so I'm wondering if a different
> >> approach would be better here. For us, there's no problem with
> >> updating any of the EVM-protected xattrs at runtime as long as doing
> >> so invalidates the iint cache entry (hmm, does setting an xattr bump
> >> the iversion? If so, we already get this behaviour). How would you
> >> feel about a runtime controllable flag that enabled this, possibly
> >> tied into the /sys/kernel/security/evm write? We'd end up with:
> >>
> >> 1: Enable HMAC
> >> 2: Enable RSA
> >> 4: Permit extended attribute writes
> >>
> >> Existing behaviour would be preserved since 1 would lock down the
> >> interface, and we could reject cases where 1 and 4 are set
> >> simultaneously.
> >
> > Here's an alternative, though admittedly one that is more difficult to
> > implement and dependent on having a portable EVM signature type.
> >
> > Define the equivalent of listxattr that allows writing multiple
> > xattrs. Change option 4 above to "Permit writing a group of extended
> > attributes, including an EVM signature, when none currently exist."
>
> This would require adding a new syscall (including glibc support), and
> I think that's probably a hard sell for a single usecase. Looking at
> the code a bit more, are you sure about this? I thought IMA_NEW_FILE
> would only be cleared once the last writer closes the fd, so it ought
> to be possible to do multiple fsetxattr()s with the same file
> descriptor until the last writer closes it?
The IMA_NEW_FILE check is applicable only when there are no security
xattrs (INTEGRITY_NOXATTRS), which would not be the case after writing
the first security xattr. The return result in that case is
INTEGRITY_NOLABEL, meaning no security.evm.
Mimi
next prev parent reply other threads:[~2017-10-18 18:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-17 23:12 Writing out EVM protected xattrs while EVM is active Matthew Garrett
2017-10-18 1:49 ` Mimi Zohar
2017-10-18 2:02 ` Matthew Garrett
2017-10-18 2:08 ` Mimi Zohar
2017-10-18 2:13 ` Matthew Garrett
2017-10-18 2:53 ` Mimi Zohar
2017-10-18 17:27 ` Matthew Garrett
2017-10-18 17:51 ` Mimi Zohar
2017-10-18 18:08 ` Matthew Garrett
2017-10-18 18:19 ` Mimi Zohar [this message]
2017-10-18 18:23 ` Matthew Garrett
2017-10-18 18:38 ` Mimi Zohar
[not found] ` <CACE9dm_vpTi705PJxGZkeNWUyHALZzVc2x=RUw_p=DZCPZfoXw@mail.gmail.com>
2017-10-18 18:18 ` Matthew Garrett
2017-10-19 11:14 ` Dmitry Kasatkin
2017-10-18 18:19 ` Dmitry Kasatkin
2017-10-19 11:00 ` Dmitry Kasatkin
2017-10-19 17:06 ` 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=1508350783.4510.22.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=dmitry.kasatkin@gmail.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 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).