Description of problem:
As part of the UEFI Secure Boot feature, a new utility called mokutil is being provided by the shim package. This is used to enroll "machine owner keys" in UEFI from userspace. Currently, SELinux is giving denials for this which prevents it from working.
Version-Release number of selected component (if applicable):
selinux-policy-3.11.1-60.fc18.noarch
How reproducible:
Always
Steps to Reproduce:
1. sudo mount -t efivarfs none /sys/firmware/efi/efivars
2. sudo mokutil --password (or similar command)
3.
Actual results:
mokutil fails with an EPERM error and the following SELinux denial:
[jwboyer@localhost src]$ sudo sealert -l eda3471d-9cdd-4a49-8aa4-c328ba47ff96
SELinux is preventing /usr/bin/mokutil from associate access on the filesystem MokPW-605dab50-e046-4300-abb6-3dd810dd8b23.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that mokutil should be allowed associate access on the MokPW-605dab50-e046-4300-abb6-3dd810dd8b23 filesystem by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep mokutil /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
/bin/sh: audit2allow: command not found
-R: audit2allow: command not found
Additional Information:
Source Context unconfined_u:object_r:unlabeled_t:s0
Target Context system_u:object_r:unlabeled_t:s0
Target Objects MokPW-605dab50-e046-4300-abb6-3dd810dd8b23 [
filesystem ]
Source mokutil
Source Path /usr/bin/mokutil
Port <Unknown>
Host localhost.localdomain
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.11.1-60.fc18.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name localhost.localdomain
Platform Linux localhost.localdomain 3.6.10-2.fc18.x86_64
#1 SMP Tue Dec 11 11:55:21 EST 2012 x86_64 x86_64
Alert Count 16
First Seen 2012-12-10 10:29:53 EST
Last Seen 2012-12-11 13:03:19 EST
Local ID eda3471d-9cdd-4a49-8aa4-c328ba47ff96
Raw Audit Messages
type=AVC msg=audit(1355248999.684:93): avc: denied { associate } for pid=1110 comm="mokutil" name="MokPW-605dab50-e046-4300-abb6-3dd810dd8b23" scontext=unconfined_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
Hash: mokutil,unlabeled_t,unlabeled_t,filesystem,associate
audit2allow
audit2allow -R
Expected results:
SELinux policy exists and allows mokutil to work with the efivarfs filesystem.
Additional info:
mokutil basically just manipulates and creates new EFI variables through the efivarfs filesystem that is mounted. When changing the password for MoK, it will create 'MokPW-<uuid>', when enrolling a new key it will create 'MokNew-<uuid>', and 'MokAuth-<uuid>' all under /sys/firmware/efi/efivars/.
I've CC'd Peter Jones and Matthew Garrett in case there are further questions.
[95244.225086] SELinux: initialized (dev efivarfs, type efivarfs), not configured for labeling
You need a policy statement to make this genfs I would presume. Not sure what is going to need access. I'd go with a new efivars_t and we'll figure it out as we go?
Comment 7Fedora Update System
2012-12-18 06:53:00 UTC
selinux-policy-3.11.1-66.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Description of problem: As part of the UEFI Secure Boot feature, a new utility called mokutil is being provided by the shim package. This is used to enroll "machine owner keys" in UEFI from userspace. Currently, SELinux is giving denials for this which prevents it from working. Version-Release number of selected component (if applicable): selinux-policy-3.11.1-60.fc18.noarch How reproducible: Always Steps to Reproduce: 1. sudo mount -t efivarfs none /sys/firmware/efi/efivars 2. sudo mokutil --password (or similar command) 3. Actual results: mokutil fails with an EPERM error and the following SELinux denial: [jwboyer@localhost src]$ sudo sealert -l eda3471d-9cdd-4a49-8aa4-c328ba47ff96 SELinux is preventing /usr/bin/mokutil from associate access on the filesystem MokPW-605dab50-e046-4300-abb6-3dd810dd8b23. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that mokutil should be allowed associate access on the MokPW-605dab50-e046-4300-abb6-3dd810dd8b23 filesystem by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep mokutil /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp /bin/sh: audit2allow: command not found -R: audit2allow: command not found Additional Information: Source Context unconfined_u:object_r:unlabeled_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects MokPW-605dab50-e046-4300-abb6-3dd810dd8b23 [ filesystem ] Source mokutil Source Path /usr/bin/mokutil Port <Unknown> Host localhost.localdomain Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.11.1-60.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.6.10-2.fc18.x86_64 #1 SMP Tue Dec 11 11:55:21 EST 2012 x86_64 x86_64 Alert Count 16 First Seen 2012-12-10 10:29:53 EST Last Seen 2012-12-11 13:03:19 EST Local ID eda3471d-9cdd-4a49-8aa4-c328ba47ff96 Raw Audit Messages type=AVC msg=audit(1355248999.684:93): avc: denied { associate } for pid=1110 comm="mokutil" name="MokPW-605dab50-e046-4300-abb6-3dd810dd8b23" scontext=unconfined_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem Hash: mokutil,unlabeled_t,unlabeled_t,filesystem,associate audit2allow audit2allow -R Expected results: SELinux policy exists and allows mokutil to work with the efivarfs filesystem. Additional info: mokutil basically just manipulates and creates new EFI variables through the efivarfs filesystem that is mounted. When changing the password for MoK, it will create 'MokPW-<uuid>', when enrolling a new key it will create 'MokNew-<uuid>', and 'MokAuth-<uuid>' all under /sys/firmware/efi/efivars/. I've CC'd Peter Jones and Matthew Garrett in case there are further questions.