[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <35960.1612199062@warthog.procyon.org.uk>
Date: Mon, 01 Feb 2021 17:04:22 +0000
From: David Howells <dhowells@...hat.com>
To: Jan =?ISO-8859-1?Q?L=FCbbe?=
<jlu@...gutronix.de>
Cc: dhowells@...hat.com, Mimi Zohar <zohar@...ux.ibm.com>,
Jarkko Sakkinen <jarkko@...nel.org>,
Ahmad Fatoum <a.fatoum@...gutronix.de>,
James Bottomley <jejb@...ux.ibm.com>, keyrings@...r.kernel.org,
Sumit Garg <sumit.garg@...aro.org>,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, kernel@...gutronix.de
Subject: Re: Migration to trusted keys: sealing user-provided key?
Jan Lübbe <jlu@...gutronix.de> wrote:
> > > ... But at this point, you can still do 'keyctl read' on that key, exposing
> > > the key material to user space.
> >
> > I wonder if it would help to provide a keyctl function to mark a key as being
> > permanently unreadable - so that it overrides the READ permission bit.
> >
> > Alternatively, you can disable READ and SETATTR permission - but that then
> > prevents you from removing other perms if you want to :-/
>
> That would mean using user type keys, right? Then we'd still have the core
> problem how a master key can be protected against simply reading it from
> flash/disk, as it would be unencrypted in this scenario.
It would apply to any type of key or keyring on which it was set. It would
cause keyctl_read() on a flagged key to return EPERM.
David
Powered by blists - more mailing lists