Received-SPF: pass (google.com: domain of linux-kernel+bounces-179272-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 15 May 2024 03:00:20 +0300
Message-Id: <D19RYHHHEZXS.2QI6ZNR60X0A5@kernel.org>
Cc: <kernel-team@cloudflare.com>
Subject: Re: [RFC PATCH 2/2] KEYS: implement derived keys
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Jarkko Sakkinen" <jarkko@kernel.org>, "Ignat Korchagin"
 <ignat@cloudflare.com>, "James Bottomley"
 <James.Bottomley@HansenPartnership.com>, "Mimi Zohar"
 <zohar@linux.ibm.com>, "David Howells" <dhowells@redhat.com>, "Paul Moore"
 <paul@paul-moore.com>, "James Morris" <jmorris@namei.org>,
 <serge@hallyn.com>, <linux-integrity@vger.kernel.org>,
 <keyrings@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <20240503221634.44274-1-ignat@cloudflare.com>
 <20240503221634.44274-3-ignat@cloudflare.com>
 <D19QW70177QG.2YC9XL0FT7VME@kernel.org>
 <D19RM0OV7YUW.1ZEI72XQUREMQ@kernel.org>
In-Reply-To: <D19RM0OV7YUW.1ZEI72XQUREMQ@kernel.org>

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 exe=
cuting 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