Bug 1736748
| Summary: | systemd-udev: The user keyring is not linked into the session keyring | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Jeff Moyer <jmoyer> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED NOTABUG | QA Contact: | Frantisek Sumsal <fsumsal> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.2 | CC: | dan.j.williams, dhowells, dtardon, fjc, systemd-maint-list, yizhan |
| Target Milestone: | rc | Flags: | msekleta:
mirror+
|
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-07-22 17:10:21 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jeff Moyer
2019-08-01 20:47:06 UTC
Um, that dracut line should have been: dracut -f /boot/initramfs-`uname -r`.img `uname -r` --install keyctl Whoops! Trying to load evm-key in dracut using the 97masterkey and 98integrity modules from the upstream dracut git repo. 97masterkey loads the kmk-user.blob: pre-pivot/60-masterkey.sh@64(load_masterkey): info 'Loading the kernel master key' pre-pivot/60-masterkey.sh@65(load_masterkey): keyctl add user kmk-user '...' @u 60-masterkey.sh@70(load_masterkey): return 0 But, 98integrity fails to load the evm-user.blob: : Session Keyring : 809562929 --alswrv 0 0 keyring: _ses : 98782915 ----s-rv 0 0 \_ user: invocation_id pre-pivot/61-evm-enable.sh@48(load_evm_key): keyctl add encrypted evm-key 'load default user:kmk-user 64 ...' @u : add_key: Required key not available pre-pivot/61-evm-enable.sh@50(load_evm_key): info 'integrity: failed to load the EVM encrypted key: evm-key' pre-pivot/61-evm-enable.sh@51(load_evm_key): return 1 After boot: Session Keyring 132420879 --alswrv 0 0 keyring: _ses 319303296 --alswrv 0 65534 \_ keyring: _uid.0 510913995 --alswrv 0 0 \_ user: kmk-user And, the same keyctl add encrypted evm-key command works: Session Keyring 132420879 --alswrv 0 0 keyring: _ses 319303296 --alswrv 0 65534 \_ keyring: _uid.0 510913995 --alswrv 0 0 \_ user: kmk-user 501353903 --alswrv 0 0 \_ encrypted: evm-key Like the original poster, running keyctl link @u @s gets past that: pre-pivot/61-evm-enable.sh@42(load_evm_key): keyctl show : Session Keyring : 870034873 --alswrv 0 0 keyring: _ses : 1010636326 ----s-rv 0 0 \_ user: invocation_id pre-pivot/61-evm-enable.sh@43(load_evm_key): keyctl link @u @s pre-pivot/61-evm-enable.sh@44(load_evm_key): keyctl show : Session Keyring : 870034873 --alswrv 0 0 keyring: _ses : 1010636326 ----s-rv 0 0 \_ user: invocation_id : 1049739001 --alswrv 0 65534 \_ keyring: _uid.0 : 87760311 --alswrv 0 0 \_ user: kmk-user pre-pivot/61-evm-enable.sh@50(load_evm_key): keyctl add encrypted evm-key 'load default user:kmk-user 64 ...' @u pre-pivot/61-evm-enable.sh@50(load_evm_key): EVMKEYID=... pre-pivot/61-evm-enable.sh@135(enable_evm): evm_configured=1 pre-pivot/61-evm-enable.sh@146(enable_evm): info 'Enabling EVM' And, after boot: # cat /sys/kernel/security/evm 1 This is intentional behavior for KeyringMode=private (the default for system services). From systemd.exec(5):
KeyringMode=
Controls how the kernel session keyring is set up for the service (see session-
keyring(7) for details on the session keyring). Takes one of inherit, private,
shared. If set to inherit no special keyring setup is done, and the kernel's
default behaviour is applied. If private is used a new session keyring is
allocated when a service process is invoked, and it is not linked up with any
user keyring. This is the recommended setting for system services, as this
ensures that multiple services running under the same system user ID (in
particular the root user) do not share their key material among each other. If
shared is used a new session keyring is allocated as for private, but the user
keyring of the user configured with User= is linked into it, so that keys
assigned to the user may be requested by the unit's processes. In this modes
multiple units running processes under the same user ID may share key material.
Unless inherit is selected the unique invocation ID for the unit (see below) is
added as a protected key by the name "invocation_id" to the newly created session
keyring. Defaults to private for services of the system service manager and to
inherit for non-service units and for services of the user service manager.
|