From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
Tadeusz Struk <tadeusz.struk@intel.com>,
dwmw2@infradead.org, keyrings@vger.kernel.org,
linux-crypto@vger.kernel.org,
linux-security-module@vger.kernel.org,
Petko Manolov <petkan@mip-labs.com>,
"Mark D. Baushke" <mdb@juniper.net>
Subject: Re: [RFC] KEYS: Exposing {a,}symmetric key ops to userspace and other bits
Date: Wed, 02 Dec 2015 14:27:52 -0500 [thread overview]
Message-ID: <1449084472.2652.20.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <1448203311.2546.34.camel@linux.vnet.ibm.com>
On Sun, 2015-11-22 at 09:41 -0500, Mimi Zohar wrote:
> On Fri, 2015-11-20 at 11:07 +0000, David Howells wrote:
> >
> > (*) Add Mimi's patches to allow keys/keyrings to be marked undeletable. This
> > is for the purpose of creating blacklists and to prevent people from
> > removing entries in the blacklist. Note that only the kernel can create
> > a blacklist - we don't want userspace generating them as a way to take up
> > kernel space.
> >
> > I think the right way to do this is to not allow marked keys to be
> > unlinked from marked keyrings, but to allow marked keys to be unlinked
> > from ordinary keyrings.
> >
> > The reason the 'keep' mark is required on individual keys is to prevent
> > the keys from being directly revoked, expired or invalidated by keyctl
> > without reference to the keyring. Marked keys that are set expirable
> > when they're created will still expire and be subsequently removed and if
> > a marked key or marked keyring loses all its references it still gets
> > gc'd.
>
> Agreed. I'll fix and re-post soon.
In addition to Petko's 3 patches, the ima-keyrings branch
(git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git) contains these two patches.
d939a88 IMA: prevent keys on the .ima_blacklist from being removed
77f33b5 KEYS: prevent keys from being removed from specified keyrings
As the IMA patch is dependent on the KEYS patch, do you mind if the KEYS
patch would be upstreamed together with this patch set?
Mimi
prev parent reply other threads:[~2015-12-02 19:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-20 11:07 [RFC] KEYS: Exposing {a,}symmetric key ops to userspace and other bits David Howells
2015-11-22 14:41 ` Mimi Zohar
2015-12-02 19:27 ` Mimi Zohar [this message]
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=1449084472.2652.20.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=mdb@juniper.net \
--cc=petkan@mip-labs.com \
--cc=tadeusz.struk@intel.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).