Description of problem: SELinux is preventing virtlogd from 'read' accesses on the chr_file random. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to allow authlogin to nsswitch use ldap Then you must tell SELinux about this by enabling the 'authlogin_nsswitch_use_ldap' boolean. Do setsebool -P authlogin_nsswitch_use_ldap 1 ***** Plugin catchall (11.6 confidence) suggests ************************** If you believe that virtlogd should be allowed read access on the random chr_file 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 'virtlogd' --raw | audit2allow -M my-virtlogd # semodule -X 300 -i my-virtlogd.pp Additional Information: Source Context system_u:system_r:virtlogd_t:s0-s0:c0.c1023 Target Context system_u:object_r:random_device_t:s0 Target Objects random [ chr_file ] Source virtlogd Source Path virtlogd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.2-32.fc29.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.19.0-0.rc1.git0.1.fc30.x86_64 #1 SMP Mon Aug 27 13:01:19 UTC 2018 x86_64 x86_64 Alert Count 2 First Seen 2018-08-29 08:47:50 +05 Last Seen 2018-08-29 20:38:11 +05 Local ID 85ff61f4-c20b-476d-a988-bd3f18b761ee Raw Audit Messages type=AVC msg=audit(1535557091.350:720): avc: denied { read } for pid=7600 comm="virtlogd" name="random" dev="devtmpfs" ino=1032 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0 Hash: virtlogd,virtlogd_t,random_device_t,chr_file,read Version-Release number of selected component: selinux-policy-3.14.2-32.fc29.noarch Additional info: component: selinux-policy reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.19.0-0.rc1.git4.1.fc30.x86_64 type: libreport
Hi Libvirt, Guys, do you have any idea why virtlogd is trying to read /dev/random device? THanks, Lukas.
I don't believe we do it explicitly, so my guess is its caused from an ELF constructor from some 3rd party library we link to. eg gnutls
Very trivial reproducer is to call "systemctl stop virtlogd" (assumption is that it is already running :-) And previous assumption was quite good. But it happens in destructor. (gdb) bt #0 __libc_open64 (file=file@entry=0x7fc77c3251dd "/dev/random", oflag=oflag@entry=0) at ../sysdeps/unix/sysv/linux/open64.c:37 #1 0x00007fc77c27d334 in open (__oflag=0, __path=0x7fc77c3251dd "/dev/random") at /usr/include/bits/fcntl2.h:53 #2 get_random_device (n=1) at crypto/rand/rand_unix.c:349 #3 0x00007fc77c27d3d7 in open_random_devices () at crypto/rand/rand_unix.c:383 #4 rand_pool_init () at crypto/rand/rand_unix.c:392 #5 0x00007fc77c27c4b2 in do_rand_init () at crypto/rand/rand_lib.c:331 #6 do_rand_init_ossl_ () at crypto/rand/rand_lib.c:315 #7 0x00007fc77c823057 in __pthread_once_slow (once_control=0x7fc77c3aa888 <rand_init>, init_routine=0x7fc77c27c470 <do_rand_init_ossl_>) at pthread_once.c:116 #8 0x00007fc77c823115 in __GI___pthread_once ( once_control=once_control@entry=0x7fc77c3aa888 <rand_init>, init_routine=init_routine@entry=0x7fc77c27c470 <do_rand_init_ossl_>) at pthread_once.c:143 #9 0x00007fc77c2baccd in CRYPTO_THREAD_run_once (once=once@entry=0x7fc77c3aa888 <rand_init>, init=init@entry=0x7fc77c27c470 <do_rand_init_ossl_>) at crypto/threads_pthread.c:113 #10 0x00007fc77c27cc9b in RAND_set_rand_method (meth=0x0) at crypto/rand/rand_lib.c:664 #11 0x00007fc77c27cd1b in rand_cleanup_int () at crypto/rand/rand_lib.c:356 #12 0x00007fc77c251975 in OPENSSL_cleanup () at crypto/init.c:555 #13 0x00007fc77c62b207 in __cxa_finalize (d=0x7fc77c37a820) at cxa_finalize.c:83 #14 0x00007fc77c14a177 in __do_global_dtors_aux () from /lib64/libcrypto.so.1.1 #15 0x00007fff86979b80 in ?? () #16 0x00007fc77ce2c0c6 in _dl_fini () at dl-fini.c:138 I assume bug is in openssl and not in libvirt.
It does not happen with older pre-release of openssl sh$ rpm -q openssl openssl-libs openssl-devel openssl-1.1.1-0.pre8.4.fc29.x86_64 openssl-libs-1.1.1-0.pre8.4.fc29.x86_64 openssl-devel-1.1.1-0.pre8.4.fc29.x86_64 And was introduced in openssl-1:1.1.1-0.pre9.1.fc30.x86_64
Please try openssl-1.1.1-0.pre9.3.fc30. It should fix the issue.
(In reply to Tomas Mraz from comment #5) > Please try openssl-1.1.1-0.pre9.3.fc30. It should fix the issue. Thank you for quick fix. AVCs are gone
*** Bug 1624552 has been marked as a duplicate of this bug. ***
*** Bug 1626012 has been marked as a duplicate of this bug. ***
*** Bug 1626013 has been marked as a duplicate of this bug. ***
pre9.1 is currently in F29 stable, so it's still hitting this, I guess. Can we please get pre9.3 for F29? Proposing as an FE issue - this bug causes AVCs which we would like not to see on the Beta lives.
openssl-1.1.1-0.pre9.3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8023936aab
Never mind, I did it myself. :) Karma on the update would be appreciated from anyone who can test.
+1 FE for beta
+1 FE
+ FE
That's +4, setting accepted.
openssl-1.1.1-0.pre9.3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1627937 has been marked as a duplicate of this bug. ***