Bug 1832231

----
type=PROCTITLE msg=audit(05/06/2020 15:11:16.549:408) : proctitle=(fwupd) 
type=PATH msg=audit(05/06/2020 15:11:16.549:408) : item=0 name=/var/lib/fwupd inode=18085630 dev=08:02 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:fwupd_var_lib_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(05/06/2020 15:11:16.549:408) : cwd=/ 
type=SYSCALL msg=audit(05/06/2020 15:11:16.549:408) : arch=x86_64 syscall=chmod success=no exit=EACCES(Permission denied) a0=0x556d92491690 a1=0755 a2=0xffffffff a3=0x0 items=1 ppid=1 pid=13045 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=(fwupd) exe=/usr/lib/systemd/systemd subj=system_u:system_r:init_t:s0 key=(null) 
type=AVC msg=audit(05/06/2020 15:11:16.549:408) : avc:  denied  { setattr } for  pid=13045 comm=(fwupd) name=fwupd dev="sda2" ino=18085630 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:fwupd_var_lib_t:s0 tclass=dir permissive=0 
----

May 06 15:11:16 localhost.localdomain systemd[1]: Starting Firmware update daemon...
May 06 15:11:16 localhost.localdomain systemd[12977]: Started D-Bus User Message Bus.
May 06 15:11:16 localhost.localdomain systemd[13045]: fwupd.service: Failed to set up special execution directory in /var/lib: Permission denied
May 06 15:11:16 localhost.localdomain systemd[13045]: fwupd.service: Failed at step STATE_DIRECTORY spawning /usr/libexec/fwupd/fwupd: Permission denied
May 06 15:11:16 localhost.localdomain systemd[1]: fwupd.service: Main process exited, code=exited, status=238/STATE_DIRECTORY
May 06 15:11:16 localhost.localdomain systemd[1]: fwupd.service: Failed with result 'exit-code'.
May 06 15:11:16 localhost.localdomain systemd[1]: Failed to start Firmware update daemon.

This bug is in NEW state. There is no selinux-policy build for RHEL-8 which would contain the fix.

This bug has not been fully acknowledged for resolving during the RHEL 8.3 development and testing phase yet. If you want to pursue this issue further, please explain what makes the severity urgent:

https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity

urgent
    catastrophic issues which severely impact the mission-critical operations of an organization. This may mean that the operational servers, development systems or customer applications are down or not functioning and no procedural workaround exists.

so that we can respond appropriately. A new build should be ready later this week.

To work around the problem, create and load a custom policy file:

  # cat local_init_mounton.cil
(allow init_t non_security_file_type (dir (write setattr mounton)))

  # semodule -i local_init_mounton.cil

Hi Zdenek, 

My understanding of this issue is blocking the fwupd service daemon and rebased gnome-software in RHEL 8.3 from their intended functionality.
In my opinion, a customer who uses our workstation should have those services available without creating custom policies

Thank you for you workaround, however, in our testing we are always using fresh rhel installations, so we would need to do it before every test run
and that is something we want to avoid, just as a reminder that this is STILL the issue for us, and therefore it can affect our customers.

Sorry, if the severity is a bit off for you but I think that we should definitely solve this in 8.3, that's why I reported it as early as we received 
rebased components and identified those issues.

*** Bug 1832234 has been marked as a duplicate of this bug. ***

*** Bug 1846369 has been marked as a duplicate of this bug. ***

SELinux policy defines the following rule:

type_transition fwupd_t var_t:dir fwupd_cache_t;

Unfortunately, the fwupd_cache_t label is not defined as default label for:

# matchpathcon /var/cache/fwupd
/var/cache/fwupd	system_u:object_r:var_t:s0
#

The automated TC identifies the discrepancy during its run:

:: [ 09:19:15 ] :: [  BEGIN   ] :: Running 'restorecon -Rv /run /var'
Relabeled /var/cache/fwupd/motd.d from system_u:object_r:fwupd_cache_t:s0 to system_u:object_r:var_t:s0
Relabeled /var/cache/fwupd/motd.d/85-fwupd from system_u:object_r:fwupd_cache_t:s0 to system_u:object_r:var_t:s0
:: [ 09:19:21 ] :: [   PASS   ] :: Command 'restorecon -Rv /run /var' (Expected 0-255, got 0)

This problem was mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1832234#c2 which was closed as a duplicate of this bug.

You're right, I missed that. So the Acceptance criteria may be united to:

Proposed acceptance criteria:
 * the fwupd service works successfully in enforcing mode
 * the fwupd service does not trigger any SELinux denials in default configuration
 * SELinux policy defines fwupd_cache_t as a default label for /var/cache/fwupd directory and everything under it

I've submitted a Fedora PR to address the latest issue:
https://github.com/fedora-selinux/selinux-policy-contrib/pull/270

Agreed.

*** Bug 1847956 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4528

*** Bug 1911854 has been marked as a duplicate of this bug. ***