On Mon, 2021-02-08 at 16:50 -0500, Mimi Zohar wrote:
> On Mon, 2021-02-08 at 15:38 +0100, Jan Lübbe wrote:
>
> > As it seems that this feature would not be appropriate for all use-cases and
> > threat models, I wonder if making it optional would be acceptable. Something
> > like:
> >
> > config
On Mon, 2021-02-08 at 15:38 +0100, Jan Lübbe wrote:
> As it seems that this feature would not be appropriate for all use-cases and
> threat models, I wonder if making it optional would be acceptable. Something
> like:
>
> config TRUSTED_KEYS_IMPORT
To me "IMPORT" implies from a trusted source,
On Mon, 2021-02-01 at 14:46 -0500, Mimi Zohar wrote:
> On Mon, 2021-02-01 at 17:38 +0100, Jan Lübbe wrote:
> > On Mon, 2021-02-01 at 11:11 -0500, Mimi Zohar wrote:
> > > On Mon, 2021-02-01 at 16:31 +0100, Jan Lübbe wrote:
> > > > On Sun, 2021-01-31 at 09:29 -0500, Mimi Zohar wrote:
> >
> > > > >
On Wed, 3 Feb 2021 at 19:16, Jan Lübbe wrote:
>
> On Wed, 2021-02-03 at 17:20 +0530, Sumit Garg wrote:
> > On Tue, 2 Feb 2021 at 18:04, Jan Lübbe wrote:
> > >
> > > On Tue, 2021-02-02 at 17:45 +0530, Sumit Garg wrote:
> > > > Hi Jan,
> > > >
> > > > On Sun, 31 Jan 2021 at 23:40, James Bottomley
On Wed, 2021-02-03 at 17:20 +0530, Sumit Garg wrote:
> On Tue, 2 Feb 2021 at 18:04, Jan Lübbe wrote:
> >
> > On Tue, 2021-02-02 at 17:45 +0530, Sumit Garg wrote:
> > > Hi Jan,
> > >
> > > On Sun, 31 Jan 2021 at 23:40, James Bottomley wrote:
> > > >
> > > > On Sun, 2021-01-31 at 15:14 +0100,
On Tue, 2 Feb 2021 at 18:04, Jan Lübbe wrote:
>
> On Tue, 2021-02-02 at 17:45 +0530, Sumit Garg wrote:
> > Hi Jan,
> >
> > On Sun, 31 Jan 2021 at 23:40, James Bottomley wrote:
> > >
> > > On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:
> > > > On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar
On Tue, 2021-02-02 at 17:45 +0530, Sumit Garg wrote:
> Hi Jan,
>
> On Sun, 31 Jan 2021 at 23:40, James Bottomley wrote:
> >
> > On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:
> > > On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:
> > > > On Sat, 2021-01-30 at 19:53 +0200, Jarkko
Hi Jan,
On Sun, 31 Jan 2021 at 23:40, James Bottomley wrote:
>
> On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:
> > On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:
> > > On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote:
> > > > On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum
On Mon, 2021-02-01 at 17:38 +0100, Jan Lübbe wrote:
> On Mon, 2021-02-01 at 11:11 -0500, Mimi Zohar wrote:
> > On Mon, 2021-02-01 at 16:31 +0100, Jan Lübbe wrote:
> > > On Sun, 2021-01-31 at 09:29 -0500, Mimi Zohar wrote:
>
> > > > Usage::
> > > >
> > > > keyctl add encrypted name "new
Jan Lübbe 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
On Mon, 2021-02-01 at 11:11 -0500, Mimi Zohar wrote:
> On Mon, 2021-02-01 at 16:31 +0100, Jan Lübbe wrote:
> > On Sun, 2021-01-31 at 09:29 -0500, Mimi Zohar wrote:
> > > Usage::
> > >
> > > keyctl add encrypted name "new [format] key-type:master-key-name
> > > keylen"
> > > ring
> >
On Mon, 2021-02-01 at 16:31 +0100, Jan Lübbe wrote:
> On Sun, 2021-01-31 at 09:29 -0500, Mimi Zohar wrote:
> > On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:
> > > On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:
> >
> >
> >
> > > >
> > > > [1] The ima-evm-utils README contains EVM
On Mon, 2021-02-01 at 11:36 +, David Howells wrote:
> Jan Lübbe 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
On Sun, 2021-01-31 at 09:29 -0500, Mimi Zohar wrote:
> On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:
> > On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:
>
>
>
> > >
> > > [1] The ima-evm-utils README contains EVM examples of "trusted" and
> > > "user" based "encrypted" keys.
> >
>
Jan Lübbe 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,
On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:
> On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:
> > On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote:
> > > On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote:
> > > > Hello,
> > > >
> > > > I've been looking into how a
On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:
> On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote:
> > On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote:
> > > Hello,
> > >
> > > I've been looking into how a migration to using trusted/encrypted keys
> > > would look like
On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:
> On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:
> >
> > [1] The ima-evm-utils README contains EVM examples of "trusted" and
> > "user" based "encrypted" keys.
>
> I assume you refer to
>
On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote:
> On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote:
> > Hello,
> >
> > I've been looking into how a migration to using trusted/encrypted keys
> > would look like (particularly with dm-crypt).
> >
> > Currently, it seems the the only
On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote:
> On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote:
> > Hello,
> >
> > I've been looking into how a migration to using trusted/encrypted
> > keys would look like (particularly with dm-crypt).
> >
> > Currently, it seems the the only
On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote:
> Hello,
>
> I've been looking into how a migration to using trusted/encrypted keys
> would look like (particularly with dm-crypt).
>
> Currently, it seems the the only way is to re-encrypt the partitions
> because trusted/encrypted keys
Hello,
I've been looking into how a migration to using trusted/encrypted keys
would look like (particularly with dm-crypt).
Currently, it seems the the only way is to re-encrypt the partitions
because trusted/encrypted keys always generate their payloads from
RNG.
If instead there was a key
22 matches
Mail list logo
