+++ 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.
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] $
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
could this bug be duplicate of 1263992
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.
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.
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.
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