[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4153718.1612179361@warthog.procyon.org.uk>
Date: Mon, 01 Feb 2021 11:36:01 +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 :-/
David
Powered by blists - more mailing lists