Description of problem: SELinux is preventing rngd from using the 'dac_override' capabilities. ***** Plugin dac_override (91.4 confidence) suggests ********************** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that rngd should have the dac_override capability 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: # ausearch -c 'rngd' --raw | audit2allow -M my-rngd # semodule -X 300 -i my-rngd.pp Additional Information: Source Context system_u:system_r:rngd_t:s0 Target Context system_u:system_r:rngd_t:s0 Target Objects Unknown [ capability ] Source rngd Source Path rngd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.1-37.fc28.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.17.12-200.fc28.x86_64 #1 SMP Fri Aug 3 15:01:13 UTC 2018 x86_64 x86_64 Alert Count 1 First Seen 2018-08-10 11:20:42 JST Last Seen 2018-08-10 11:20:42 JST Local ID 00edbe0e-3439-4ce0-bff0-dc25a8704be5 Raw Audit Messages type=AVC msg=audit(1533867642.120:89): avc: denied { dac_override } for pid=725 comm="rngd" capability=1 scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:system_r:rngd_t:s0 tclass=capability permissive=0 Hash: rngd,rngd_t,rngd_t,capability,dac_override Version-Release number of selected component: selinux-policy-3.14.1-37.fc28.noarch Additional info: component: selinux-policy reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.17.12-200.fc28.x86_64 type: libreport Potential duplicate: bug 1509274
Description of problem: Rebooted workstation after applying latest updates. Logged in. SEAlert popped up with this message. Version-Release number of selected component: selinux-policy-3.14.1-37.fc28.noarch Additional info: reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.17.12-200.fc28.x86_64 type: libreport
Hi, Do the rngd daemon require DAC_OVERRRIDE capability? We removed from distribution SELinux policy quite lot of allow rules allowing DAC_OVERRIDE capability for the deamon. In most cases it's issue on the application/daemon side, not SELinux side. For more info see following article: https://lukas-vrabec.com/index.php/2018/07/03/why-do-you-see-dac_override-selinux-denials/ I can help you to identify which file has too tight unix permissions please turn on full auditing on audit daemon and reproduce the scenario: https://lukas-vrabec.com/index.php/2018/07/16/how-to-enable-full-auditing-in-audit-daemon/ Thanks, Lukas.
Description of problem: Booted up the system, presented with this issue Version-Release number of selected component: selinux-policy-3.14.1-37.fc28.noarch Additional info: reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.17.12-200.fc28.x86_64 type: libreport
I can't see any reason why, under normal operating circumstances, rngd should require a bypass of file permissions checks. The only files it should nominally be reading/writing should be /dev/hwrng and /dev/random, both of which are owned by root, which should be the process owner as well. As such, I'm not sure why you would be getting this error message. Can you enable full auditing as Lukas suggests, and re-create the problem? Lets figure out what file access specifically rngd is tripping up on and move forward from there.
Hi Neil, See below # ausearch -m avc -ts recent ---- time->Tue Aug 14 14:42:34 2018 type=PROCTITLE msg=audit(1534246954.400:101): proctitle=2F7362696E2F726E6764002D66 type=PATH msg=audit(1534246954.400:101): item=0 name="/dev/tpm0" inode=14387 dev=00:06 mode=020660 ouid=59 ogid=59 rdev=0a:e0 obj=system_u:object_r:tpm_device_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1534246954.400:101): cwd="/" type=SYSCALL msg=audit(1534246954.400:101): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55a552479908 a2=2 a3=0 items=1 ppid=1 pid=1131 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rngd" exe="/usr/sbin/rngd" subj=system_u:system_r:rngd_t:s0 key=(null) type=AVC msg=audit(1534246954.400:101): avc: denied { dac_override } for pid=1131 comm="rngd" capability=1 scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:system_r:rngd_t:s0 tclass=capability permissive=0 This is from /var/log/audit/audit.log type=SERVICE_START msg=audit(1534246954.348:98): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=rngd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1534246954.400:101): avc: denied { dac_override } for pid=1131 comm="rngd" capability=1 scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:system_r:rngd_t:s0 tclass=capability permissive=0 type=SYSCALL msg=audit(1534246954.400:101): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55a552479908 a2=2 a3=0 items=1 ppid=1 pid=1131 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rngd" exe="/usr/sbin/rngd" subj=system_u:system_r:rngd_t:s0 key=(null)
Thank you, could you also run ls -l /dev/tpm0 for me? Lukas, I think the above is saying that rngd is getting an error because the access to /dev/tpm0 is failing, likely because /dev/tpm0 isn't owned by the root user or group, and its permission for other users doesn't include the write bit, is that correct? The ls -l above should confirm that. If so, whats the right solution here. I don't think rngd needs to have dac_override rights. I suspect that we either need to make /dev/tpm0 owned by root, thoughts?
Hi Neil # ls -l /dev/tpm0 crw-rw----. 1 tss tss 10, 224 Aug 14 17:31 /dev/tpm0 # getfacl /dev/tpm0 getfacl: Removing leading '/' from absolute path names # file: dev/tpm0 # owner: tss # group: tss user::rw- group::rw- other::---
yeah, ok, that does it, root needs to read and write that device file. Lukas, whats the best way to handle this?
Description of problem: This Happened when i started my pc Version-Release number of selected component: selinux-policy-3.14.1-37.fc28.noarch Additional info: reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.17.12-200.fc28.x86_64 type: libreport
Neil Hi, Is there any update on this?
none, lukas hasn't done anything with this bz yet. Ping again lukas, please respond
Hi, Sorry for late delay. On my system I see: # ls -l /dev/tpm0 crw-------. 1 root root 10, 224 Oct 12 11:42 /dev/tpm0 # sesearch -A -s rngd_t -t tpm_device_t 1 ↵ allow rngd_t tpm_device_t:chr_file { append getattr ioctl lock open read write }; # ps auxZ | grep rngd system_u:system_r:rngd_t:s0 root 7115 0.1 0.0 98248 4856 ? Ss 09:57 0:02 /sbin/rngd -f staff_u:staff_r:staff_t:s0:c0.c1023 lvrabec 19141 0.0 0.0 213800 1072 pts/3 R+ 10:33 0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn rngd So owner of /dev/tpm0 is root and also owner of the rngd process is root. This means that there is no need to bypassing Linux security permissions. And from SELinux POV access to /dev/tpm0 is allowed because of existing SELinux allow rule. Cenk, In our case /dev/tpm0 is owned by tss: # ls -l /dev/tpm0 crw-rw----. 1 tss tss 10, 224 Aug 14 17:31 /dev/tpm0 Do you know whats going on there?
Hi Lukas See below: $ ls -l /dev/tpm0 crw-rw----. 1 tss tss 10, 224 Oct 15 09:58 /dev/tpm0 $ cat /etc/passwd | grep tss tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin $ sudo sesearch -A -s rngd_t -t tpm_device_t allow rngd_t tpm_device_t:chr_file { append getattr ioctl lock open read write }; $ ps auxZ | grep rngd system_u:system_r:rngd_t:s0 root 1189 0.0 0.0 98248 4832 ? Ss 09:58 0:02 /sbin/rngd -f unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 cenk 8433 0.0 0.0 213800 1076 pts/0 S+ 11:45 0:00 grep --color=auto rngd $ cat /etc/os-release NAME=Fedora VERSION="28 (Workstation Edition)" ID=fedora VERSION_ID=28 PLATFORM_ID="platform:f28" PRETTY_NAME="Fedora 28 (Workstation Edition)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:28" HOME_URL="https://fedoraproject.org/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=28 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=28 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Workstation Edition" VARIANT_ID=workstation This is a Fedora 28 system which is upgraded from Fedora27. # rpm -qa | grep trouser trousers-lib-0.3.13-10.fc28.x86_64 trousers-0.3.13-10.fc28.x86_64 # rpm -qa --last trousers trousers-0.3.13-10.fc28.x86_64 Tue 08 May 2018 06:09:40 PM +03 # yum history | grep 2018-05-08 213 | system-upgrade upgrade | 2018-05-08 17:57 | D, E, I, O, U | 2300 EE # yum history info 213 | grep -i trouser -A 1 Upgraded trousers-0.3.13-9.fc27.x86_64 @fedora/27 Upgrade 0.3.13-10.fc28.x86_64 @fedora Upgraded trousers-lib-0.3.13-9.fc27.x86_64 @fedora/27 Upgrade 0.3.13-10.fc28.x86_64 @fedora
can someone clarify what this means? From my read it seems as though something during the upgrade from Fedora 27 to 28 has changed ownership on /dev/tpm0 from root to tss and something about the selinux label on /dev/tpm0 isn't triggering the allow rule to grant rngd access, but thats not clearly stated. Is that the case, and if so, what do we do about it?
Neil, I do not have access to the Fedora27 environment anymore, so someone needs to check if at Fedora 27, the ownership was different.
root@hp-dl160gen8-02 ~]# ls /dev/tpm0 /dev/tpm0 [root@hp-dl160gen8-02 ~]# ls -l /dev/tpm0 crw-------. 1 root root 10, 224 Oct 15 2018 /dev/tpm0 [root@hp-dl160gen8-02 ~]# uname -r 4.18.12-100.fc27.x86_64 [root@hp-dl160gen8-02 ~]# lsmod | grep tpm tpm_infineon 20480 0 The above was captured from hp-dl160gen8-02.khw.lab.eng.bos.redhat.com running a fresh install of Fedora 27 Server for x86_64. I belive this is a tpm 1.2 system rather than a tpm 2.0 system, if that makes any difference, but given that we're talking about device file ownership, I don't think it should.
Whole problem here is taht /dev/tpm0 is owned by somebody else than root. I don't know why but on fresh installation of Fedora it looks good. Could you please change owner of that device?
*** Bug 1639488 has been marked as a duplicate of this bug. ***
Description of problem: sudo dnf update (20181016; 16:28 CET) Version-Release number of selected component: selinux-policy-3.14.1-44.fc28.noarch Additional info: reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.18.12-200.fc28.x86_64 type: libreport
I did change it to root/root but after one of the dnf update sessions, I noticed the ownership returned to tss/tss I have changed the ownership back to root/root manually again. $ ls -l /dev/tpm0 crw-rw----. 1 tss tss 10, 224 Oct 27 12:24 /dev/tpm0 $ sudo chown root:root /dev/tpm0 $ ls -l /dev/tpm0 crw-rw----. 1 root root 10, 224 Oct 27 12:24 /dev/tpm0 I will follow this for a while.
After a reboot, the ownership is changed back to tss/tss $ ls -l /dev/tpm0 crw-rw----. 1 tss tss 10, 224 Oct 30 10:11 /dev/tpm0
I enabled auditing on /dev/tpm0, see below. I change ownership to root:root, reboot system, it is changed back to tss:tss ---- time->Tue Oct 30 10:24:20 2018 type=PROCTITLE msg=audit(1540884260.598:104): proctitle=2F7362696E2F726E6764002D66 type=PATH msg=audit(1540884260.598:104): item=0 name="/dev/tpm0" inode=14257 dev=00:06 mode=020660 ouid=59 ogid=59 rdev=0a:e0 obj=system_u:object_r:tpm_device_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1540884260.598:104): cwd="/" type=SYSCALL msg=audit(1540884260.598:104): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55907c532908 a2=2 a3=0 items=1 ppid=1 pid=1257 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rngd" exe="/usr/sbin/rngd" subj=system_u:system_r:rngd_t:s0 key="monitor-tpm" type=AVC msg=audit(1540884260.598:104): avc: denied { dac_override } for pid=1257 comm="rngd" capability=1 scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:system_r:rngd_t:s0 tclass=capability permissive=0 ---- time->Tue Oct 30 10:25:43 2018 type=PROCTITLE msg=audit(1540884343.112:293): proctitle=63686F776E00726F6F743A726F6F74002F6465762F74706D30 type=PATH msg=audit(1540884343.112:293): item=0 name="/dev/tpm0" inode=14257 dev=00:06 mode=020660 ouid=59 ogid=59 rdev=0a:e0 obj=system_u:object_r:tpm_device_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1540884343.112:293): cwd="/root" type=SYSCALL msg=audit(1540884343.112:293): arch=c000003e syscall=260 success=yes exit=0 a0=ffffff9c a1=5603cf10e8a0 a2=0 a3=0 items=1 ppid=3922 pid=3973 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="chown" exe="/usr/bin/chown" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="monitor-tpm" ---- time->Tue Oct 30 10:26:11 2018 type=PROCTITLE msg=audit(1540884371.884:295): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F6465762F74706D30 type=PATH msg=audit(1540884371.884:295): item=0 name="/dev/tpm0" inode=14257 dev=00:06 mode=020660 ouid=0 ogid=0 rdev=0a:e0 obj=system_u:object_r:tpm_device_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1540884371.884:295): cwd="/root" type=SYSCALL msg=audit(1540884371.884:295): arch=c000003e syscall=191 success=no exit=-61 a0=7ffccb3a4d01 a1=55b8ee396b7b a2=0 a3=0 items=1 ppid=3922 pid=3975 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="monitor-tpm" ---- time->Tue Oct 30 10:26:11 2018 type=PROCTITLE msg=audit(1540884371.883:294): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F6465762F74706D30 type=PATH msg=audit(1540884371.883:294): item=0 name="/dev/tpm0" inode=14257 dev=00:06 mode=020660 ouid=0 ogid=0 rdev=0a:e0 obj=system_u:object_r:tpm_device_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1540884371.883:294): cwd="/root" type=SYSCALL msg=audit(1540884371.883:294): arch=c000003e syscall=192 success=yes exit=34 a0=7ffccb3a4d01 a1=7f5095d7e03e a2=55b8eeb746d0 a3=ff items=1 ppid=3922 pid=3975 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="monitor-tpm" ---- time->Tue Oct 30 10:26:59 2018 type=CONFIG_CHANGE msg=audit(1540884419.819:92): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key="monitor-tpm" list=4 res=1 ---- time->Tue Oct 30 10:26:59 2018 type=PROCTITLE msg=audit(1540884419.919:103): proctitle=2F7362696E2F726E6764002D66 type=PATH msg=audit(1540884419.919:103): item=0 name="/dev/tpm0" inode=1159 dev=00:06 mode=020660 ouid=59 ogid=59 rdev=0a:e0 obj=system_u:object_r:tpm_device_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1540884419.919:103): cwd="/" type=SYSCALL msg=audit(1540884419.919:103): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5581abf47908 a2=2 a3=0 items=1 ppid=1 pid=1263 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rngd" exe="/usr/sbin/rngd" subj=system_u:system_r:rngd_t:s0 key="monitor-tpm" type=AVC msg=audit(1540884419.919:103): avc: denied { dac_override } for pid=1263 comm="rngd" capability=1 scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:system_r:rngd_t:s0 tclass=capability permissive=0 ---- time->Tue Oct 30 10:28:02 2018 type=PROCTITLE msg=audit(1540884482.145:292): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F6465762F74706D30 type=PATH msg=audit(1540884482.145:292): item=0 name="/dev/tpm0" inode=1159 dev=00:06 mode=020660 ouid=59 ogid=59 rdev=0a:e0 obj=system_u:object_r:tpm_device_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1540884482.145:292): cwd="/root" type=SYSCALL msg=audit(1540884482.145:292): arch=c000003e syscall=192 success=yes exit=34 a0=7ffdb4df6d01 a1=7f99f532203e a2=561a47df46d0 a3=ff items=1 ppid=3861 pid=3933 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="monitor-tpm" ---- time->Tue Oct 30 10:28:02 2018 type=PROCTITLE msg=audit(1540884482.147:293): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F6465762F74706D30 type=PATH msg=audit(1540884482.147:293): item=0 name="/dev/tpm0" inode=1159 dev=00:06 mode=020660 ouid=59 ogid=59 rdev=0a:e0 obj=system_u:object_r:tpm_device_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1540884482.147:293): cwd="/root" type=SYSCALL msg=audit(1540884482.147:293): arch=c000003e syscall=191 success=no exit=-61 a0=7ffdb4df6d01 a1=561a47a6db7b a2=0 a3=0 items=1 ppid=3861 pid=3933 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="monitor-tpm" ----
Its the udev rule, from /usr/lib/udev/rulesd/60-tpm-udev.rules: #tpm2 devices can be accessed by the tss user or tss group members KERNEL=="tpmrm[0-9]*|tpm[0-9]*", MODE="0660", OWNER="tss", GROUP="tss" You could fix it by changing ownership to root in the rule, so it would persist across reboots, but the bigger question is, why are they restricting access to the tss user and group. I wonder if the owner shouldn't be root, but the owning group tss?
Upstream tpm2-tss has a different udev rule, see https://github.com/tpm2-software/tpm2-tss/blob/master/dist/tpm-udev.rules https://src.fedoraproject.org/rpms/tpm2-tss/c/075fc2f0d3cc476d7ecc99483c1e28c2e0855535?branch=master Also I noticed, with RHEL7 it is also User:tss Group:tss see https://bugzilla.redhat.com/show_bug.cgi?id=1626069 https://bugzilla.redhat.com/show_bug.cgi?id=1592583
how is it different, it looks exactly the same to me as what I put in comment 23. Its all moot though, this seems to be the root cause, and we either need to update the selinux policy to allow rngd access to that file or change the ownership to root/tss. Which way should we go?
add root to tss group?
That feels wrong. In the default install, root belongs to the root group and thats it. Its odd to need to add root to other groups to gain file access permissions that it should just have. CC-ing the tpm2-tss maintainer for comments. Yunying, summary of the problem. rngd legitimately attempts to access the tpm for entropy extraction, but is denied access as it runs as root, and /dev/tpm0 is owned by user/group tss/tss. Ostensibly the right thing to do here is update selinux policy to allow this access, but we wanted check with you first as to why /dev/tpm0 should be owned by a user other than root? Other devices in /dev traditionally allow non root access by making the device be owned by root, and some non-root group (so that non-root users can be administratively added to said group to gain access). Can you either change the ownership of /dev/tpm* in the udev rules to be root/tss or explain why the owner has to be the tss user? Thanks!
Neil This is the upstream udev rule (from https://github.com/tpm2-software/tpm2-tss/blob/master/dist/tpm-udev.rules ): # tpm devices can only be accessed by the tss user but the tss # group members can access tpmrm devices KERNEL=="tpm[0-9]*", MODE="0660", OWNER="tss" KERNEL=="tpmrm[0-9]*", MODE="0660", OWNER="tss", GROUP="tss" And this is the Fedora udev rule # tpm2 devices can be accessed by the tss user or tss group members KERNEL=="tpmrm[0-9]*|tpm[0-9]*", MODE="0660", OWNER="tss", GROUP="tss" I did manually change the udev rule on my system to the upstream version, and after the reboot the /dev/tpm0 is owned by tss/root and /dev/tpmrm0 is owned by tss/tss as expected. $ ls -l /dev/tpm* crw-rw----. 1 tss root 10, 224 Nov 3 00:53 /dev/tpm0 crw-rw----. 1 tss tss 253, 65536 Nov 3 00:53 /dev/tpmrm0 After I did this change, there was no more SELinux alert, as root can access /dev/tpm0. $ sudo ausearch -m avc -ts recent <no matches> I noticed that the content of the udev rule Fedora uses comes from the tpm2-abrmd package (see the fix implemented at https://github.com/tpm2-software/tpm2-abrmd/issues/334 ) however afterwards the udev rules are removed from tpm2-abrmd package and moved to tpm2-tss package (see https://github.com/tpm2-software/tpm2-abrmd/issues/412 and https://github.com/tpm2-software/tpm2-tss/commit/0075f88466d791b2b58c60adafed87ec814441df#diff-f71a283cb9b3b87455c43deb6c262c1a ) So the udev rules are not inline with the upstream tpm2-tss package as far as I can see. Am I missing something?
No, you're not missing anything, I missed the fact that there were different rules upstream (I accepted the fedora version blindly as being in sync with upstream). I find it a bit odd that the rule just lets the group value default to root rather than explicitly stating it outright, but thats probably not overly relevant here. So I think we've found our root cause. I'll transfer this to the tpm2-tss component to have them sync up the tpm udev rules with upstream so that rngd has appropriate access to the /dev/tpmX device set
tpm2-tss-1.4.0-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1d2676532d
tpm2-tss-1.4.0-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1d2676532d
Description of problem: Boot the system Version-Release number of selected component: selinux-policy-3.14.1-51.fc28.noarch Additional info: reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.20.6-100.fc28.x86_64 type: libreport
Hi, why is this still on QA? kind regards Sven
Let me know if you'd like a volunteer to test the solution. I get this error upon every boot on my system that has a TPM2.
tpm2-tss-1.4.0-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
Terriblly sorry for missing this ticket for almost 2 years.. Fedora now has v3.0 for tpm2-tss. Please create new bugzilla if issue still exists.