Re: [PATCH v9 0/8] TPM 2.0 trusted keys with attached policy

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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