RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1960705 - Vino nonfunctional in FIPS mode
Summary: Vino nonfunctional in FIPS mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: vino
Version: 8.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: beta
: 8.5
Assignee: Ondrej Holy
QA Contact: Bohdan Milar
URL:
Whiteboard:
Depends On:
Blocks: 1972176
TreeView+ depends on / blocked
 
Reported: 2021-05-14 16:11 UTC by Andrew Mike
Modified: 2021-11-10 07:29 UTC (History)
10 users (show)

Fixed In Version: vino-3.22.0-11.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1972176 (view as bug list)
Environment:
Last Closed: 2021-11-09 19:34:22 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Fix crashes under FIPS (1.53 KB, patch)
2021-06-15 11:32 UTC, Ondrej Holy 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 6061231 0 None None None 2021-05-19 20:22:51 UTC
Red Hat Product Errata RHSA-2021:4381 0 None None None 2021-11-09 19:34:42 UTC

Description Andrew Mike 2021-05-14 16:11:26 UTC 
Description of problem: Vino does not work when global FIPS mode is enabled.


Version-Release number of selected component (if applicable):
3.22.0-10.el8

How reproducible: 100%


Steps to Reproduce:
1. Install new RHEL 8.3 system with FIPS mode enabled (fips=1 in kernel mode parameters during initial install) and "Server with GUI" installation option selected.
2. Log in to GNOME and enable remote desktop sharing as normal.
3. Allow port 5900 in firewall.
4. Attempt to connect to VNC from second system.

Actual results:
- VNC client hangs at attempting to display desktop.
- If the system is set up to prompt user to grant vino access, prompt appears and functions as normal, but even if permitted, desktop still will not display/
- If a password is used instead, password prompt is not displayed on VNC client.

Expected results:
VNC connection through vino works as normal.

Additional info:
- Disabling FIPS allows VNC connection to work properly.
Comment 1 Ondrej Holy 2021-05-18 12:30:34 UTC 
If the prompt appears as normal, then gnome-remote-desktop is probably used (Wayland), not vino (X11). Because, in my case, gnome-remote-desktop crashes when connecting when the FIPS mode is enabled, whereas vino crashes immediately. Can you confirm it? If so, please change the component, or perhaps clone the bug. Because both seem to crash because DH_BITS is 1024, which causes that gnutls_dh_params_generate2 returns 0 when the FIPS mode is enabled. Consequently, gnutls_anon_set_server_dh_params crashes because of that. It seems that DH_BITS change to 2048 should fix this. This seems to be the same as https://bugzilla.redhat.com/show_bug.cgi?id=1492107 for tigervnc, which uses the http://pkgs.devel.redhat.com/cgit/rpms/tigervnc/tree/tigervnc-working-tls-on-fips-systems.patch?h=rhel-9.0.0-beta patch currently. It is probably safe as it is part of tigervnc for some time already, but I wonder why the same change was not made upstream...

Process 3923 (vino-server) of user 1000 dumped core.
Stack trace of thread 3923:
#0  0x00007f64845f01f4 __gmpz_sizeinbase (libgmp.so.10)
#1  0x00007f648c603e72 wrap_nettle_mpi_get_nbits (libgnutls.so.30)
#2  0x00007f648c51dbd8 gnutls_anon_set_server_dh_params (libgnutls.so.30)
#3  0x0000564c4f0ee9e2 rfbGetScreen (vino-server)
#4  0x0000564c4f0e256e vino_server_set_property (vino-server)
#5  0x00007f648c8bb379 g_object_new_internal (libgobject-2.0.so.0)
#6  0x00007f648c8bcf4e g_object_new_valist (libgobject-2.0.so.0)
#7  0x00007f648c8bd2ad g_object_new (libgobject-2.0.so.0)
#8  0x0000564c4f0dd876 name_acquired (vino-server)
#9  0x00007f648cbc9696 do_call (libgio-2.0.so.0)
#10 0x00007f648cbc98a8 request_name_cb (libgio-2.0.so.0)
#11 0x00007f648cb8b784 g_task_return_now (libgio-2.0.so.0)
#12 0x00007f648cb8c236 g_task_return (libgio-2.0.so.0)
#13 0x00007f648cbc116a g_dbus_connection_call_done (libgio-2.0.so.0)
#14 0x00007f648cb8b784 g_task_return_now (libgio-2.0.so.0)
#15 0x00007f648cb8b7bd complete_in_idle_cb (libgio-2.0.so.0)
#16 0x00007f648bbc21eb g_idle_dispatch (libglib-2.0.so.0)
#17 0x00007f648bbc58ad g_main_context_dispatch (libglib-2.0.so.0)
#18 0x00007f648bbc5c78 g_main_context_iterate.isra.21 (libglib-2.0.so.0)
#19 0x00007f648bbc5fa2 g_main_loop_run (libglib-2.0.so.0)
#20 0x0000564c4f0da08c main (vino-server)
#21 0x00007f6489cd9493 __libc_start_main (libc.so.6)
#22 0x0000564c4f0da18e _start (vino-server)

Process 7059 (gnome-remote-de) of user 1000 dumped core. 
Stack trace of thread 7059:
#0  0x00007f23a536d1f4 __gmpz_sizeinbase (libgmp.so.10)
#1  0x00007f23a8dade72 wrap_nettle_mpi_get_nbits (libgnutls.so.30)
#2  0x00007f23a8cc7bd8 gnutls_anon_set_server_dh_params (libgnutls.so.30)
#3  0x000055a39358799c ensure_tls_context (gnome-remote-desktop-daemon)
#4  0x000055a393587ac5 rfb_tls_security_handler (gnome-remote-desktop-daemon)
#5  0x00007f23a94c3348 rfbProcessClientSecurityType (libvncserver.so.0)
#6  0x00007f23a94be435 rfbProcessClientMessage (libvncserver.so.0)
#7  0x00007f23a94c5020 rfbCheckFds (libvncserver.so.0)
#8  0x00007f23a94bb84b rfbProcessEvents (libvncserver.so.0)
#9  0x000055a39357fbfb vnc_socket_grab_func (gnome-remote-desktop-daemon)
#10 0x000055a393580715 grd_session_vnc_dispatch (gnome-remote-desktop-daemon)
#11 0x000055a3935807d2 handle_socket_data (gnome-remote-desktop-daemon)
#12 0x00007f23a9c8bccd socket_source_dispatch (libgio-2.0.so.0)
#13 0x00007f23a9fff8ad g_main_context_dispatch (libglib-2.0.so.0)
#14 0x00007f23a9fffc78 g_main_context_iterate.isra.21 (libglib-2.0.so.0)
#15 0x00007f23a9fffd10 g_main_context_iteration (libglib-2.0.so.0)
#16 0x00007f23a9cb210d g_application_run (libgio-2.0.so.0)
#17 0x000055a393575c57 main (gnome-remote-desktop-daemon)
#18 0x00007f23a86a4493 __libc_start_main (libc.so.6)
#19 0x000055a393575d5e _start (gnome-remote-desktop-daemon)
Comment 2 Andrew Mike 2021-06-14 15:25:34 UTC 
It seems to be vino-server crashing whether it's a Wayland or X11 session. But yes, it does crash on startup on 8.4 now.
Comment 3 Andrew Mike 2021-06-14 15:50:11 UTC 
In addition, the backtrace is the same as what you observed.
Comment 4 Ondrej Holy 2021-06-15 11:32:13 UTC 
Created attachment 1791237 [details]
Fix crashes under FIPS
Comment 5 Ondrej Holy 2021-06-15 11:35:30 UTC 
Thanks for the confirmation. The attached patch should fix it as per my testing.
Comment 7 Ondrej Holy 2021-06-23 14:10:45 UTC 
Just a note that the patch needs to be changed to make it work also with FIPS 140-3, see https://github.com/TigerVNC/tigervnc/pull/1273.
Comment 9 Bohdan Milar 2021-06-24 10:37:04 UTC 
I used a modified reproducer to reproduce the bug and verify the vino-3.22.0-10.test.el8.x86_64 scratch build:

1. Activate FIPS in an already installed (and running) RHEL 8:
sudo fips-mode-setup --enable
2. Reboot the system and login to Gnome (on X.org)
3. Enable VNC in firewall:
sudo firewall-cmd --add-service=vnc-server
4. Start Vino from command line:
/usr/libexec/vino-server

Actual results (vino-3.22.0-10.el8.x86_64):
Error message: Segmentation fault (core dumped)

Expected results (vino-3.22.0-10.test.el8.x86_64):
Correct start with output like this:
24/06/2021 11:25:19 AM Autoprobing TCP port in (all) network interface
24/06/2021 11:25:19 AM Listening IPv6://[::]:5900
24/06/2021 11:25:19 AM Listening IPv4://0.0.0.0:5900
...

If there are no objections, I will try to create an automated test based on this reproducer.
Comment 14 Bohdan Milar 2021-07-15 14:14:38 UTC 
Verified manually on x86_64, aarch64, ppc64le, s390x
using my reproducer (see comment 9) with FIPS enabled.

vino-3.22.0-10.el8 - core dump on all arches
vino-3.22.0-11.el8 - starts correctly on all arches

Result: fix verified.
Comment 16 errata-xmlrpc 2021-11-09 19:34:22 UTC 
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 (Moderate: GNOME security, 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/RHSA-2021:4381
Note You need to log in before you can comment on or make changes to this bug.