public inbox for linux-integrity@vger.kernel.org
 help / color / mirror / Atom feed
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>
Cc: <kernel-team@cloudflare.com>
Subject: Re: [RFC PATCH 2/2] KEYS: implement derived keys
Date: Wed, 15 May 2024 03:00:20 +0300	[thread overview]
Message-ID: <D19RYHHHEZXS.2QI6ZNR60X0A5@kernel.org> (raw)
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 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

  reply	other threads:[~2024-05-15  0:00 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-03 22:16 [RFC PATCH 0/2] TPM derived keys Ignat Korchagin
2024-05-03 22:16 ` [RFC PATCH 1/2] tpm: add some algorithm and constant definitions from the TPM spec Ignat Korchagin
2024-05-14 22:51   ` Jarkko Sakkinen
2024-05-14 22:52     ` Jarkko Sakkinen
2024-05-03 22:16 ` [RFC PATCH 2/2] KEYS: implement derived keys Ignat Korchagin
2024-05-14 23:10   ` Jarkko Sakkinen
2024-05-14 23:44     ` Jarkko Sakkinen
2024-05-15  0:00       ` Jarkko Sakkinen [this message]
2024-05-15  6:44       ` Ignat Korchagin
2024-05-15 12:00         ` Jarkko Sakkinen
2024-05-15 12:03           ` Jarkko Sakkinen
2024-05-15  7:26     ` Ignat Korchagin
2024-05-04  0:21 ` [RFC PATCH 0/2] TPM " Jarkko Sakkinen
2024-05-04 13:55   ` Ben Boeckel
2024-05-04 14:51     ` Jarkko Sakkinen
2024-05-04 15:35       ` Jarkko Sakkinen
2024-05-13 17:09         ` Ignat Korchagin
2024-05-13 22:33           ` James Bottomley
2024-05-14  9:50             ` Ignat Korchagin
2024-05-14 14:11               ` James Bottomley
2024-05-14 14:54                 ` Ignat Korchagin
2024-05-13 17:11 ` Ignat Korchagin
2024-05-14  0:28   ` Jarkko Sakkinen
2024-05-14 10:05     ` Ignat Korchagin
2024-05-14 12:09       ` Jarkko Sakkinen
2024-05-14 13:11         ` Ignat Korchagin
2024-05-14 14:00           ` Jarkko Sakkinen
2024-05-14 14:30             ` Jarkko Sakkinen
2024-05-14 15:21               ` Jarkko Sakkinen
2024-05-14 15:26                 ` Jarkko Sakkinen
2024-05-14 15:30                   ` Ignat Korchagin
2024-05-14 15:42                     ` Jarkko Sakkinen
2024-05-14 16:08                       ` Ignat Korchagin
2024-05-14 16:22                         ` Jarkko Sakkinen
2024-05-14 14:41             ` Ignat Korchagin
2024-05-14 14:45               ` Jarkko Sakkinen
2024-05-14 15:30           ` James Bottomley
2024-05-14 15:38             ` Ignat Korchagin
2024-05-14 15:54               ` James Bottomley
2024-05-14 16:01                 ` Ignat Korchagin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D19RYHHHEZXS.2QI6ZNR60X0A5@kernel.org \
    --to=jarkko@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dhowells@redhat.com \
    --cc=ignat@cloudflare.com \
    --cc=jmorris@namei.org \
    --cc=kernel-team@cloudflare.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox