Bug 1624554 - SELinux is preventing virtlogd from 'read' accesses on the chr_file random.
Summary: SELinux is preventing virtlogd from 'read' accesses on the chr_file random.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: 29
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:e402258f52bc7d35dec3e86445b...
: 1624552 1626012 1626013 1627937 (view as bug list)
Depends On:
Blocks: F29BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2018-09-01 10:49 UTC by Mikhail
Modified: 2018-09-15 22:13 UTC (History)
23 users (show)

Fixed In Version: openssl-1.1.1-0.pre9.3.fc30 openssl-1.1.1-0.pre9.3.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-12 03:00:49 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openssl openssl issues 7136 None None None 2018-09-06 11:24:35 UTC

Description Mikhail 2018-09-01 10:49:34 UTC
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

Comment 1 Lukas Vrabec 2018-09-05 11:37:20 UTC
Hi Libvirt, 

Guys, do you have any idea why virtlogd is trying to read /dev/random device? 

THanks,
Lukas.

Comment 2 Daniel Berrangé 2018-09-05 11:40:16 UTC
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

Comment 3 Lukas Slebodnik 2018-09-06 08:52:42 UTC
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.

Comment 4 Lukas Slebodnik 2018-09-06 09:03:12 UTC
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

Comment 5 Tomas Mraz 2018-09-06 12:40:58 UTC
Please try openssl-1.1.1-0.pre9.3.fc30. It should fix the issue.

Comment 6 Lukas Slebodnik 2018-09-06 15:05:16 UTC
(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

Comment 7 Lukas Slebodnik 2018-09-06 18:46:01 UTC
*** Bug 1624552 has been marked as a duplicate of this bug. ***

Comment 8 Lukas Vrabec 2018-09-07 13:10:48 UTC
*** Bug 1626012 has been marked as a duplicate of this bug. ***

Comment 9 Lukas Vrabec 2018-09-07 13:10:49 UTC
*** Bug 1626013 has been marked as a duplicate of this bug. ***

Comment 10 Adam Williamson 2018-09-11 19:00:38 UTC
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.

Comment 11 Fedora Update System 2018-09-11 19:50:16 UTC
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

Comment 12 Adam Williamson 2018-09-11 19:51:25 UTC
Never mind, I did it myself. :) Karma on the update would be appreciated from anyone who can test.

Comment 13 Paul Whalen 2018-09-11 21:26:15 UTC
+1 FE for beta

Comment 14 Stephen Gallagher 2018-09-11 21:44:08 UTC
+1 FE

Comment 15 Matthew Miller 2018-09-11 21:46:25 UTC
+1 FE

Comment 16 Mohan Boddu 2018-09-11 21:46:56 UTC
+ FE

Comment 17 Adam Williamson 2018-09-11 22:53:38 UTC
That's +4, setting accepted.

Comment 18 Fedora Update System 2018-09-12 03:00:49 UTC
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.

Comment 19 Lukas Vrabec 2018-09-15 22:13:10 UTC
*** Bug 1627937 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.