unable to show the contents of my kernel keyring

Bug #400484 reported by Dustin Kirkland 
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
Fix Released
High
Unassigned
keyutils (Ubuntu)
Invalid
High
Unassigned
linux (Ubuntu)
Won't Fix
High
Andy Whitcroft

Bug Description

Running the command:
 $ keyctl show

I should see something like the following:
kirkland@t61p:~$ keyctl show
Session Keyring
       -3 --alswrv 1000 -1 keyring: _uid_ses.1000
698440950 --alswrv 1000 -1 \_ keyring: _uid.1000
575594151 --alswrv 1000 0 \_ user: 67354f2e3a6c1216
940463712 --alswrv 1000 0 \_ user: 1cb12fd405033223

And this is true, if I run the Jaunty 2.6.28 kernel on Karmic.

However, this is completely broken with the 2.6.31 Karmic kernel.

kirkland@x200:~$ keyctl show
Session Keyring
       -3 --alswrv 1000 1000 keyring: _ses

Major regression. Hoses ecryptfs, which relies on keyutils.

:-Dustin

ProblemType: Bug
Architecture: amd64
Date: Thu Jul 16 21:32:48 2009
DistroRelease: Ubuntu 9.10
MachineType: LENOVO 7454CTO
Package: linux-image-2.6.31-3-generic 2.6.31-3.19
ProcCmdLine: root=UUID=d45ce184-de1d-48ac-a143-44ab4432a207 ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-3.19-generic
RelatedPackageVersions: linux-backports-modules-2.6.31-3-generic N/A
SourcePackage: linux
Uname: Linux 2.6.31-3-generic x86_64
dmi.bios.date: 04/22/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 6DET44WW (2.08 )
dmi.board.name: 7454CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6DET44WW(2.08):bd04/22/2009:svnLENOVO:pn7454CTO:pvrThinkPadX200:rvnLENOVO:rn7454CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7454CTO
dmi.product.version: ThinkPad X200
dmi.sys.vendor: LENOVO

CVE References

Revision history for this message
Dustin Kirkland  (kirkland) wrote :
Changed in linux (Ubuntu):
status: New → Confirmed
importance: Undecided → High
tags: added: regression-potential
Changed in ecryptfs-utils (Ubuntu):
importance: Undecided → High
Changed in keyutils (Ubuntu):
importance: Undecided → High
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Found a work around for now.

While 'keyctl show' does not work, 'keyctl list @u' does. Use that for now.

:-Dustin

Changed in ecryptfs-utils (Ubuntu):
status: New → In Progress
assignee: nobody → Dustin Kirkland (kirkland)
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.4 KiB)

This bug was fixed in the package ecryptfs-utils - 76-0ubuntu1

---------------
ecryptfs-utils (76-0ubuntu1) karmic; urgency=low

  [ Dustin Kirkland ]
  * src/utils/ecryptfs-setup-swap: switch from vol_id to blkid,
    LP: #376486
  * debian/ecryptfs-utils.postinst, src/utils/ecryptfs-setup-private:
    don't echo mount passphrase if running in bootstrap mode; prune
    potential leakages from install log, LP: #383650
  * SECURITY UPDATE: mount passphrase recorded in install log (LP: #383650).
    - debian/ecryptfs-utils.postinst: prune private information from
      installer log
    - src/utils/ecryptfs-setup-private: don't echo passphrase if running in
      bootstrap mode
    - CVE-2009-1296
  * src/utils/ecryptfs-setup-private: make some of the lanuage more readable,
    (thanks, anrxc)
  * README, configure.ac, debian/control, debian/rules,
    doc/sourceforge_webpage/README, src/libecryptfs-swig/libecryptfs.py,
    src/libecryptfs-swig/libecryptfs_wrap.c,
    src/libecryptfs/key_management.c, src/libecryptfs/libecryptfs.pc.in,
    src/libecryptfs/main.c, src/pam_ecryptfs/Makefile.am,
    src/utils/manager.c, src/utils/mount.ecryptfs.c: move build from gcrypt
    to nss (this change has been pending for some time)
  * src/utils/ecryptfs-dot-private: dropped, was too hacky
  * ecryptfs-mount-private.1, ecryptfs-setup-private.1: align the
    documentation and implementation of the wrapping-independent feature,
    LP: #383746
  * src/utils/ecryptfs-umount-private: use keyctl list @u, since keyctl show
    stopped working, LP: #400484, #395082
  * src/utils/mount.ecryptfs_private.c: fix counter file locking; solves
    a longstanding bug about "random" umount caused by cronjobs, LP: #358573

  [ Michal Hlavinka (edits by Dustin Kirkland) ]
  * doc/manpage/ecryptfs-mount-private.1,
    doc/manpage/ecryptfs-rewrite-file.1,
    doc/manpage/ecryptfs-setup-private.1, doc/manpage/ecryptfs.7,
    doc/manpage/mount.ecryptfs_private.1,
    doc/manpage/umount.ecryptfs_private.1: documentation updated to note
    possible ecryptfs group membership requirements; Fix ecrypfs.7 man
    page and key_mod_openssl's error message; fix typo
  * src/libecryptfs/decision_graph.c: put a finite limit (5 tries) on
    interactive input; fix memory leaks when asking questions
  * src/libecryptfs/module_mgr.c: Don't error out with EINVAL when
    verbosity=0 and some options are missing.
  * src/utils/umount.ecryptfs.c: no error for missing key when removing it
  * src/libecryptfs-swig/libecryptfs.i: fix compile werror, cast char*
  * src/utils/ecryptfs_add_passphrase.c: fix/test/use return codes;
    return nonzero for --fnek when not supported but used
  * src/include/ecryptfs.h, src/key_mod/ecryptfs_key_mod_openssl.c,
    src/libecryptfs/module_mgr.c: refuse mounting with too small rsa
    key (key_mod_openssl)
  * src/utils/ecryptfs_insert_wrapped_passphrase_into_keyring.c: fix return
    codes
  * src/utils/ecryptfs-rewrite-file: polish output
  * src/libecryptfs/key_management.c: inform about full keyring; insert fnek
    sig into keyring if fnek support check fails; don't fail if key already
    exists in keyring
  * src/utils/ecryptfs-setup-private: if th...

Read more...

Changed in ecryptfs-utils (Ubuntu):
status: Fix Committed → Fix Released
Andy Whitcroft (apw)
Changed in linux (Ubuntu):
assignee: nobody → Andy Whitcroft (apw)
status: Confirmed → In Progress
Revision history for this message
Andy Whitcroft (apw) wrote :

I am suspicious that this is a side effect of the commit below. This seems to limit results to those in specific namespaces.

  commit 1d1e97562e5e2ac60fb7b25437ba619f95f67fab
  Author: Serge E. Hallyn <email address hidden>
  Date: Thu Feb 26 18:27:38 2009 -0600

    keys: distinguish per-uid keys in different namespaces

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

I can't reproduce this as yet. With a plain, fresh pull from Linus' tree on a rhel5.3 system,
I get the following. Can you confirm that in your case, with the commands below, you do
not see the last line in the 'keyctl show' output?

with user namespaces:

[root@linuz11 ~]# keyctl add user mykey stuff @u
743079327
[root@linuz11 ~]# keyctl list @u
1 key in keyring:
743079327: --alswrv 0 0 user: mykey
[root@linuz11 ~]# keyctl show
Session Keyring
       -3 --alswrv 0 0 keyring: _ses
713825872 --alswrv 0 -1 \_ keyring: _uid.0
743079327 --alswrv 0 0 \_ user: mykey
[root@linuz11 ~]# uname -a
Linux linuz11.watson.ibm.com 2.6.31-rc3-00157-gaea1f79 #582 SMP Wed Jul 22 13:14:37 EDT 2009 s390x s390x s390x GNU/Linux

without user namespaces:

[root@linuz11 ~]# keyctl add user mykey stuff @u
113989424
[root@linuz11 ~]# keyctl list @u
1 key in keyring:
113989424: --alswrv 0 0 user: mykey
[root@linuz11 ~]# keyctl show
Session Keyring
       -3 --alswrv 0 0 keyring: _ses
653741632 --alswrv 0 -1 \_ keyring: _uid.0
113989424 --alswrv 0 0 \_ user: mykey

Revision history for this message
Dustin Kirkland  (kirkland) wrote : Re: [Bug 400484] Re: unable to show the contents of my kernel keyring

kirkland@x200:/local/virt/img$ keyctl add user mykey stuff @u
976692306
kirkland@x200:/local/virt/img$ keyctl list @u
1 key in keyring:
976692306: --alswrv 1000 1000 user: mykey
kirkland@x200:/local/virt/img$ keyctl show
Session Keyring
       -3 --alswrv 1000 1000 keyring: _ses
kirkland@x200:/local/virt/img$ uname -a
Linux x200 2.6.31-3-generic #19-Ubuntu SMP Tue Jul 14 16:07:02 UTC
2009 x86_64 GNU/Linux

:-Dustin

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Using git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git, both with and without
CONFIG_USER_NS, it works for me:

[hallyn@linuz11 ~]$ keyctl add user mykey stuff @u
351981811
[hallyn@linuz11 ~]$ keyctl show
Session Keyring
       -3 --alswrv 501 501 keyring: _ses
456819210 --alswrv 501 -1 \_ keyring: _uid.501
351981811 --alswrv 501 501 \_ user: mykey
[hallyn@linuz11 ~]$ keyctl list @u
1 key in keyring:
351981811: --alswrv 501 501 user: mykey

Dustin, can you post your .config?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Also the result of

strace keyct list @u

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Attached.

:-Dustin

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Bisect shows the behavior changes as of the commit:

d84f4f992cbd76e8f39c488cf0c5d123843923b1 CRED: Inaugurate COW credentials

Since it is a by-product of such a huge change i assume it was inadvertent.

Revision history for this message
David Howells (dhowells) wrote :

> kirkland@t61p:~$ keyctl show
> Session Keyring
> -3 --alswrv 1000 -1 keyring: _uid_ses.1000
> 698440950 --alswrv 1000 -1 \_ keyring: _uid.1000
> 575594151 --alswrv 1000 0 \_ user: 67354f2e3a6c1216
> 940463712 --alswrv 1000 0 \_ user: 1cb12fd405033223

Interesting. You shouldn't have seen this at all. PAM should have given you your own session keyring when you logged in, which should be called "_ses". "_uid_ses.<UID>" is the backup session keyring you fall back to if you don't get a session keyring for some reason.

PAM (pam_keyinit.so) should then make a link to the user keyring in the session keyring. This is done in userspace, not in the kernel.

Can you try stracing "su - kirkland" from root? I see:

keyctl(0x1, 0, 0xffffffffffffffff, 0xfcb, 0) = 355497645
keyctl(0x8, 0xfffffffc, 0xfffffffd, 0, 0x1132700) = 0

which is KEYCTL_JOIN_SESSION_KEYRING followed by KEYCTL_LINK.

David

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Yes I maintain that on my RHEL5.3 partition (which is at the moment inaccessible) I couldn't
reproduce this with the latest kernel. The bisection was done on a SLES partition. So PAM
seems a very likely suspect. I think Tyler had mentioned something like that yesterday too.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

So we're not using pam_keyinit.so.

Instead, we're using pam_ecryptfs.so to load the keys, and then mount
an ecryptfs home or private directory.

Perhaps we're doing something there.

When I run:
 # strace su - kirkland 2>/tmp/strace

I don't see any keyctl() calls at all.

:-Dustin

Revision history for this message
David Howells (dhowells) wrote :

You should use both, pam_keyinit.so first, so that each log-in session gets its own session keyring. The kernel will, under some circumstances, give you a session keyring if you don't have one and are falling back to the user-session keyring - any call which modifies a keyring, for example, if given the session keyring special ID will create the session keyring if it does not exist.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Okay, after adding pam_keyinit.so just before pam_ecryptfs.so in the
PAM configuration, I now can see the two keyctl calls in the strace.

...
keyctl(0, 0xfffffffd, 0, 0x7f084e6c5280, 0x7fff8c4ba1b0) = 683056049
keyctl(0, 0xfffffffb, 0, 0x7fff8c4ba1b0, 0x169fd20) = 97213900
...

"keyctl show" still doesn't provide any useful information, while
"keyctl list @u" does.

Does the pam_ecryptfs.so code need to do anything different, now that
we're using pam_keyinit.so?

:-Dustin

Revision history for this message
David Howells (dhowells) wrote :

> "keyctl show" still doesn't provide any useful information, while "keyctl list @u" does.

Example, please.

David

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

On my RHEL5.3 partition, /etc/pam.d/login has at the end:

session optional pam_keyinit.so force revoke

When I remove that line, keyctl show does not list the user keys. With that line,
it does. With 2.6.31-rc3.

Revision history for this message
Andy Whitcroft (apw) wrote :

@dustin -- to summarise the current position the kernel does seem to have changed behaviour, this may be deliberate. Our userspace differs from that in RHEL where it does work with a similarly configured kernel. ecryptfs is working ok with the mods, and the investigation continues centering on the pam config. I'll assume you'll let us know if there is a kernel issue here.

Changed in linux (Ubuntu):
status: In Progress → Incomplete
tags: added: regression-release
removed: regression-potential
tags: added: karmic
Andy Whitcroft (apw)
Changed in linux (Ubuntu):
status: Incomplete → Won't Fix
Changed in keyutils (Ubuntu):
status: New → Invalid
Changed in ecryptfs-utils (Ubuntu):
assignee: Dustin Kirkland (kirkland) → nobody
status: Fix Released → Invalid
status: Invalid → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.