Bug 1406868

+++ This bug was initially created as a clone of Bug #1357994 +++

+++ This bug was initially created as a clone of Bug #1263992 +++

Description of problem:

mokutil fails to update or clear password, fails to reset. No related avc denials and nothing in the logs.

Version-Release number of selected component (if applicable):

# cat /etc/redhat-release 
Fedora release 22 (Twenty Two)

# uname -r
4.0.8-300.fc22.x86_64

# rpm -q mokutil
mokutil-0.2.0-1.fc22.x86_64


How reproducible:
Always

Steps to Reproduce:
# mokutil  --password
input password: 
input password again: 
Failed to write MokPW

# mokutil --reset
input password: 
input password again: 
Failed to write MokAuth
Failed to issue a reset request

Actual results:


Expected results:


Additional info:

--- Additional comment from Adam Przedniczek on 2015-11-08 13:27:44 EST ---

I've just installed Fedora 23 with UEFI support on Asus X99 Deluxe motherboard (BIOS v. 1901) and I have the same problems with mokutil.
I want to enroll my public X.509 DER key into MOK list, according to 23.7.4.3. subsection in
https://docs.fedoraproject.org/en-US/Fedora/23/html/System_Administrators_Guide/sect-enrolling-public-key-on-target-system.html
I cannot: set password, clear password, import with root password, import with password given at the fly (I know that's foolish).

# mokutil --password
input password: 
input password again: 
Failed to write MokPW

# mokutil --clear-password
Failed to write MokPW

# mokutil --root-pw --password
Failed to write MokPW

# mokutil --import public_key.der        // Here, I'm naively using root password
input password: 
input password again: 
Failed to enroll new keys

# mokutil --root-pw --import public_key.der 
Failed to enroll new keys

At the beginning, I thought that this mokutil behaviour is the result of the SELINUX policy zeal, but I haven't found any traces of AVC denials.
Maybe that's not true bug, but I'm using something incorrecly?

# uname -r
4.2.5-300.fc23.x86_64

# rpm -q mokutil
mokutil-0.2.0-3.fc23.x86_64

--- Additional comment from Adam Przedniczek on 2015-11-16 17:39:08 EST ---

I have just found a workaround to my problem with mokutil.

I added my public key do system_keyring via UEFI BIOS option.
Why it took so long? Because of the BIOS strange bahaviour.
UEFI BIOS > Advanced Mode > Boot > Secure Boot > Key Management > Append Default db
After pressing 'Append Default db' press 'No' (according to the description included),
choose a DER file and you should see dialog box asking to select key type:
List with two enties:
1. Key Certificate blob (highlited in yellow)
2. Uefi Serure Variable
and of course two buttons: OK and Cancel.

MOST INTERESTING PART:
Pressing OK with highlited right option makes a delusion that the key will be stored,
but ONLY HITTING WITH A MOUSE THE FIRST LIST ENTRY 'Key Certificate blob' saves the key.
Why? I have no idea, but it works in this manner.

I wonder if (at least my) problem with mokutil could be caused by inappropriate BIOS software.

--- Additional comment from Knut J BJuland on 2016-02-05 03:34:03 EST ---

I have the same problem I am using asus x99-a/usb 3.1 with  Vendor: American Megatrends Inc. Version: 2001

--- Additional comment from Knut J BJuland on 2016-02-05 03:54:06 EST ---

This affect Fedora f23 as well.

--- Additional comment from Gayland G. Gump on 2016-05-15 12:24:34 EDT ---

Real world example:  Trying to install Oracle's VirtualBox 5.O which comes with unsigned kernel modules from Oracle's repository. Since mok-utils is not working it is not possible to register a personally created key.  Consequence is that system must be run with Secure Boot mode turned off in order to use VirtualBox.  This is all part of an effort to support a non-profit organization.  Hope this helps to bump the bug higher up the priority queue.

Running this on a Dell XPS 8500 - uname -r 4.4.9-300.fc23.x86_64

--- Additional comment from Mangirdas on 2016-06-10 07:47:35 EDT ---

Same with Lenovo T460s with fedora 4.5.6-200.fc23.x86_64

Any progress on this?

--- Additional comment from todd on 2016-06-10 21:57:42 EDT ---

I'm having the same situation with mokutil not working. This affects Fedora 23.

pretty much any mokutil command used results in errors. When I try to import a key so I can sign and use Virtualbox modules I get the following.
Failed to write MokAuth
Failed to unset MokNew

then when I reboot the import fails.


Lenovo E460
Fedora 23


If there is anything I can do to help please just ask.

--- Additional comment from Fedora End Of Life on 2016-07-19 13:55:13 EDT ---

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--- Additional comment from Gayland G. Gump on 2016-07-19 14:59:34 EDT ---

Note the final four comments on this bug all reference Fedora 23 so clearly EOL on Fedora 22 is not a sufficient reason to kill this bug it still exists in 23.

--- Additional comment from Knut J BJuland on 2016-07-20 21:24:39 EDT ---

Hi I get the same error with Fedora 24

udo mokutil --import public_key.der 
input password: 
input password again: 
Failed to enroll new keys
[knutjbj@uefi_knut nvidia_key] $

--- Additional comment from todd on 2016-07-26 13:06:43 EDT ---


I am currently using Fedora 24 on a Lenovo e460.
When I try to import a key using mokutil --import pub.der I get the following error:
'Failed to set variable (2) Invalid parameter'
And as you could guess, the key is not imported.

Kernel:
4.6.4-301.fc24.x86_64
kernel-devel:
4.6.4-301.fc24.x86_64

mokutil: 
0.3.0-1.fc24.x86_64


While I was still using fedora 23 I would receive that same error as listed above,  but I would also receive other errors, such as:
mokutil --password 
Failed to write MokPW

--- Additional comment from Knut J BJuland on 2016-08-02 01:04:21 EDT ---

could this bug be duplicate of 1263992

--- Additional comment from Tomasz Kepczynski on 2016-08-23 14:50:09 EDT ---

I have similar issue (as already noted above):
[root@localhost ~]# /mnt/usr/bin/strace -o zzz mokutil --import /mnt/root/MOK.der 
input password: 
input password again: 
Failed to enroll new keys

From the strace log:

open("/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
read(4, "", 4)                          = 0
close(4)                                = 0
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_CONTINUE or SNDRV_TIMER_IOCTL_GPARAMS or TCSETSF, {B38400 opost isig icanon -echo ...}) = 0
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
write(1, "input password: ", 16)        = 16
read(0, "1234\n", 1024)                 = 5
ioctl(0, SNDCTL_TMR_CONTINUE or SNDRV_TIMER_IOCTL_GPARAMS or TCSETSF, {B38400 opost isig icanon echo ...}) = 0
write(1, "\n", 1)                       = 1
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_CONTINUE or SNDRV_TIMER_IOCTL_GPARAMS or TCSETSF, {B38400 opost isig icanon -echo ...}) = 0
write(1, "input password again: ", 22)  = 22
read(0, "1234\n", 1024)                 = 5
ioctl(0, SNDCTL_TMR_CONTINUE or SNDRV_TIMER_IOCTL_GPARAMS or TCSETSF, {B38400 opost isig icanon echo ...}) = 0
write(1, "\n", 1)                       = 1
futex(0x7f7bfef1b0a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=86698, ...}) = 0
mmap(NULL, 86698, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7c0075b000
close(3)                                = 0
open("/lib64/libnspr4.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\314\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=253136, ...}) = 0
close(3)                                = 0
munmap(0x7f7c0075b000, 86698)           = 0
open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "0\n", 1024)                    = 2
close(3)                                = 0
open("/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23", O_WRONLY|O_CREAT, 0644) = -1 EACCES (Permission denied)
write(2, "Failed to enroll new keys\n", 26) = 26

Note permission error when opening MokNew* for write.

I've tried to remove the file:

[root@localhost ~]# /mnt/usr/bin/strace -o zzz rm /sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23 
rm: cannot remove '/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23': Operation not permitted

and relevant strace log:

newfstatat(AT_FDCWD, "/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid()                               = 0
unlinkat(AT_FDCWD, "/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23", 0) = -1 EPERM (Operation not permitted)

The interesting part is that I CAN modify boot order variables.

It looks like for whatever reason kernel is somehow restricting access to Mok* efi variables. Could it be somehow related to the issue of bricking UEFI platform with `rm -rf /'?

I used Fedora 24 x86_64 Workstation Live CD downloaded yesterday for the above checks.

This issue also exists on up to date CentOS 7.2 and very likely - on RHEL 7.2.

--- Additional comment from Fedora End Of Life on 2016-11-25 04:26:52 EST ---

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from Fedora End Of Life on 2016-12-20 16:13:58 EST ---

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--- Additional comment from Knut J BJuland on 2016-12-21 01:48:00 EST ---

I have the same problem in Fedora 25.

sudo mokutil --password
input password: 
input password again: 
Failed to write MokPW: Invalid argument

 sudo mokutil --clear-password
Failed to write MokPW: Invalid argument