linux-kernel - Re: [RFC PATCH 2/2] KEYS: implement derived keys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 15 May 2024 03:00:20 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>, "Ignat Korchagin"
 <ignat@...udflare.com>, "James Bottomley"
 <James.Bottomley@...senPartnership.com>, "Mimi Zohar"
 <zohar@...ux.ibm.com>, "David Howells" <dhowells@...hat.com>, "Paul Moore"
 <paul@...l-moore.com>, "James Morris" <jmorris@...ei.org>,
 <serge@...lyn.com>, <linux-integrity@...r.kernel.org>,
 <keyrings@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Cc: <kernel-team@...udflare.com>
Subject: Re: [RFC PATCH 2/2] KEYS: implement derived keys

On Wed May 15, 2024 at 2:44 AM EEST, Jarkko Sakkinen wrote:
> >
> > What is "key length"? Please refer the exact attribute.
> >
> > >
> > > User id is mixed, so different users get different keys even when executing the
> >
> > First of all it would be more clear to just s/User id/UID/
> >
> > And make obvious whether we are talking about ruid or euid and how
> > this interacts with GIDs.
> >
> > I'll look at the code change next round if the commit message starts
> > making any sense.
>
> Right and neither UIDs and GIDs are applicable for key derivation for
> quite obvious reasons. So NAK for that too.
>
> You can make them point out unlimited different identities...

Please drop the whole stateless system argument from the next patch
set version. It looks to me that only it has been considered and we
don't even have definition what it is. I think it only distorts
and confuses and is totally app specific in the end of the day.

This looks more like a tool for identity theft than a key in its
current state. This could never ever exist in a "stateful system"
and this mainline code base so would be quite irresponsible to ever
take this.

There's only one attribute I'm aware that you could ever possibly
use for key derivation: mm_struct->exe_file.

BR, Jarkko