The GConf settings we've been using for login banners and disabling user lists have been replaced by Gnome 3's dconf parameters in RHEL 7 (and Fedora, obviously). dconf allows users and admins to set certain parameters with plain text key files. It also allows admins to bypass key files and set parameters with a GVariant binary blob file. There are some problems for us with both methods. I'll use the login banner text settings as an example.

The recommended method in the RHEL 7 administration guide is to create a text file in /etc/dconf/db/gdm.d/ that looks something like the following:

[org/gnome/login-screen]
banner-message-enable=true
banner-message-text='Consent banner text'

After creating this file, the user must type dconf update, and the settings are applied, making this a two step process. However, there is a second way to apply the same settings, using the gsettings tool, which will write the data as a binary data blob into the home directory of whatever user runs the tool:

sudo -u gdm dbus-launch gsettings set org.gnome.login-screen banner-message-enable true

This achieves the same effect and the consent banner will be displayed to users in exactly the same way. This method is harder to test, since there is no parseable text file for OVAL to evaluate, but it is extremely easy to apply on the command line.


TLDR: Are we allowed to mandate that system administrators must use the Red Hat guide's method of using plain text key files?


On a related note, the login banner text only displays AFTER users have put in their user name, and there appears to be no way to edit the consent banner's appearance without altering the GDM theme. Instead, it's scrunched into a tiny window, with tiny grey text on a grey background, with a scroll bar. Is it too late to put this on my RHEL 7 final release wish list or can someone point me to the correct settings?

- Maura Dailey
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Reply via email to