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?

On Monday, February 24, 2014 06:07:22 PM Maura Dailey wrote: > 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? Yes. That is the best way. I was involved with a bz a while back to work out the method and that is what they came up with: https://bugzilla.redhat.com/show_bug.cgi?id=817594

I would be concerned if a setting in the local directory could be used to suppress the login banner. But doing the central configuration is the best thing to do. Also, in terms of meeting other NIST controls during login, be aware of this bz, too (comment 8 details the enhanced control that can be met): https://bugzilla.redhat.com/show_bug.cgi?id=915371 -Steve > 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 > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Hello, Missed this section... On Monday, February 24, 2014 06:07:22 PM Maura Dailey wrote: > 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? There are a couple settings here that we care about. One is you need to do this to to avoid leaking accounts: disable-user-list=true I know the gnome developers were concerned about the real estate available when the user list was being shown + a banner. Not sure how it finally ended up as I recall hearing them say they might kick it to an interstitial screen if there was not enough room because the text was too large or users were being displayed. That said, when I worked at NASA, we had machines where you logged in, it went to an interstitial page where you accepted the consent to be monitored, and if not it kicked you back to the login screen. If you accepted, you got the whole CDE desktop. The point being that you couldn't do any real work until you accepted and it did kick you out such that you couldn't do anything unless you accepted. So, if gnome follows that...it might be different than rhel6, but still valid as a work flow. -Steve

On Tuesday, February 25, 2014 11:41:51 AM Maura Dailey wrote: > disable-user-list has been set to true in my testing, and the box is > still ridiculously tiny and at the very bottom of the screen. I was told this is a known problem: bz 1061996 - Modify GDM to present a sufficiently visible login banner in RHEL7 and its fixed in gnome-shell-3.8.4-24.el7 -Steve > I wouldn't > mind an interstitial screen, actually, because it would probably mean > the text could be displayed with the same size font as the login > prompts. The security auditors around here prefer to see the banner > before the user login process begins. It's the way that RHEL 6, Mac OS > X, and Windows handles it currently. That doesn't mean I can't talk them > around to showing it halfway through the process, but it is irksome that > Gnome 3 is switching the order around, apparently for aesthetics. > > I did file an RFE, if only to get some official suggestions, but I'm > going to start pursuing how much of the appearance is controlled by the > theme and how much is configurable. Making the text a brighter color > instead of a light grey would be a huge improvement all by itself. > However, if the box size is not configurable, then making the text > bigger might be painful to scroll through. > > - Maura Dailey > > On 02/24/2014 07:33 PM, Steve Grubb wrote: >> Hello, >> >> Missed this section... >> >> On Monday, February 24, 2014 06:07:22 PM Maura Dailey wrote: >>> 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? >> There are a couple settings here that we care about. One is you need to do >> this to to avoid leaking accounts: >> >> disable-user-list=true >> >> I know the gnome developers were concerned about the real estate available >> when the user list was being shown + a banner. Not sure how it finally >> ended up as I recall hearing them say they might kick it to an >> interstitial screen if there was not enough room because the text was too >> large or users were being displayed. >> >> That said, when I worked at NASA, we had machines where you logged in, it >> went to an interstitial page where you accepted the consent to be >> monitored, and if not it kicked you back to the login screen. If you >> accepted, you got the whole CDE desktop. The point being that you >> couldn't do any real work until you accepted and it did kick you out such >> that you couldn't do anything unless you accepted. So, if gnome follows >> that...it might be different than rhel6, but still valid as a work flow. >> >> -Steve