From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
"Kayaalp, Mehmet" <Mehmet.Kayaalp@unh.edu>
Cc: Jerry Snitselaar <jsnitsel@redhat.com>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
Mimi Zohar <zohar@linux.ibm.com>,
David Woodhouse <dwmw2@infradead.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
David Howells <dhowells@redhat.com>
Subject: Re: [PATCH v9 0/8] TPM 2.0 trusted keys with attached policy
Date: Sun, 17 May 2020 00:44:38 +0300 [thread overview]
Message-ID: <9a7fe3f44bb5772eb6c8cdac04d042190d4a53e1.camel@linux.intel.com> (raw)
In-Reply-To: <1589584989.30847.20.camel@HansenPartnership.com>
On Fri, 2020-05-15 at 16:23 -0700, James Bottomley wrote:
> On Fri, 2020-05-15 at 15:19 -0700, James Bottomley wrote:
> > On Fri, 2020-05-15 at 21:03 +0000, Kayaalp, Mehmet wrote:
> > > > On May 15, 2020, at 4:10 PM, James Bottomley <James.Bottomley@han
> > > > se
> > > > npartnership.com> wrote:
> > > >
> > > > I think that means the solution is not to run the smoke test
> > > > under sudo but to do sudo -s and then run it.
> > > >
> > > > James
> > >
> > > How about "sudo -i":
> > >
> > > https://askubuntu.com/questions/376199/sudo-su-vs-sudo-i-vs-sudo-
> > > bin-bash-when-does-it-matter-which-is-used
> >
> > Actually, no that doesn't work either:
> >
> > jejb@testdeb> sudo -i keyctl list @s
> > 1 key in keyring:
> > 1041514063: ---lswrv 1000 65534 keyring: _uid.1000
> >
> > I suspect this might be a very subtle bug to do with when you get a
> > new session keyring.
>
> It turns out to be incredibly subtle, but I'm not sure if it's a bug or
> not. the util-linux sudo like commands have special pam profiles
>
> /etc/pam.d/su-l
> /etc/pam.d/runuser-l
>
> These special profiles call pam_keyinit.so with flags to install a new
> session keyring. sudo doesn't have this, so it never, on its own, even
> when called with -i or -s, installs a new session keyring. This does
> strike me as a bizarre oversight which leads directly to this weird
> keyctl pipe behaviour.
>
> I'm also not sure the keyctl pipe behaviour is correct: why should
> keyctl pipe deny access to root to read a key just because it's in a
> different session keyring? It defintely seems intentional, because if
> I create a key as a non root user and try to print it by id as root I
> get EPERM.
>
> The weirdest behaviour, though seems to be keyctl: keyctl add ... @u
> will add to the session keyrings of the actual uid regardless of what
> session keyring the creator actually has, which is why keyctl add ...
> @u works under sudo but you get EPERM back trying to pipe it by id.
>
> James
I think I construct a low priority bug to kernel bugzilla and link these
from l.k.o. Thanks for digging this all up.
/Jarkko
next prev parent reply other threads:[~2020-05-16 21:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 23:11 [PATCH v9 0/8] TPM 2.0 trusted keys with attached policy James Bottomley
2020-05-07 23:11 ` [PATCH v9 1/8] lib: add ASN.1 encoder James Bottomley
2020-05-17 8:17 ` Sakkinen, Jarkko
2020-05-07 23:11 ` [PATCH v9 2/8] oid_registry: Add TCG defined OIDS for TPM keys James Bottomley
2020-05-07 23:11 ` [PATCH v9 3/8] security: keys: trusted: fix TPM2 authorizations James Bottomley
2020-05-14 1:11 ` Jarkko Sakkinen
2020-05-14 1:12 ` Jarkko Sakkinen
2020-05-14 1:41 ` James Bottomley
2020-05-14 11:19 ` Jarkko Sakkinen
2020-05-07 23:11 ` [PATCH v9 4/8] security: keys: trusted: use ASN.1 TPM2 key format for the blobs James Bottomley
2020-05-17 8:18 ` Sakkinen, Jarkko
2020-05-07 23:11 ` [PATCH v9 5/8] security: keys: trusted: Make sealed key properly interoperable James Bottomley
2020-05-07 23:11 ` [PATCH v9 6/8] security: keys: trusted: add PCR policy to TPM2 keys James Bottomley
2020-05-07 23:11 ` [PATCH v9 7/8] security: keys: trusted: add ability to specify arbitrary policy James Bottomley
2020-05-07 23:11 ` [PATCH v9 8/8] security: keys: trusted: implement counter/timer policy James Bottomley
2020-05-14 14:31 ` [PATCH v9 0/8] TPM 2.0 trusted keys with attached policy Jarkko Sakkinen
2020-05-15 2:22 ` Jarkko Sakkinen
2020-05-15 3:44 ` James Bottomley
2020-05-15 8:47 ` Jarkko Sakkinen
2020-05-15 9:30 ` Jerry Snitselaar
2020-05-15 18:48 ` James Bottomley
2020-05-16 12:24 ` Jarkko Sakkinen
2020-05-16 9:59 ` Jarkko Sakkinen
2020-05-15 19:17 ` Jerry Snitselaar
2020-05-15 19:34 ` James Bottomley
2020-05-15 19:50 ` Mimi Zohar
2020-05-15 20:10 ` James Bottomley
2020-05-15 21:03 ` Kayaalp, Mehmet
2020-05-15 22:19 ` James Bottomley
2020-05-15 23:23 ` James Bottomley
2020-05-16 21:44 ` Jarkko Sakkinen [this message]
2020-05-16 13:01 ` Sakkinen, Jarkko
2020-05-16 12:33 ` Jarkko Sakkinen
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=9a7fe3f44bb5772eb6c8cdac04d042190d4a53e1.camel@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Mehmet.Kayaalp@unh.edu \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=jsnitsel@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).