But We Want a Pre-Authentication Consent Banner!

My primary client-base is security- and compliance-focussed. As part of this, they follow security guidelines that include things like "system must display consent-to-monitor banners".

Up until recently, I only ever worked on the server end of things — almost exclusively UNIX- or Linux-based (though, the past decade has been almost exclusively Linux). This meant that all I really had to worry about was ensuring a suitable /etc/issue file was in place and that any interactive login services (mostly SSH; occasionally FTP) were configured to reference that file."

Any GUI-dependent developers that my customers might have had did all of their development work on Windows boxes or specially-prepared Linux desktops. In either case, they were using on-premises desktops that I didn't have to worry about.

With COVID19 and the mass adoption of telework, those carefully-prepared development desktops are sitting disused at my customers offices. Developers have been forced to work remote. As such, we've been asked, as part of our "enablement" mandate, to help these newly-remote developers set up cloud-hosted development-systems. A significant percentage of these developers rely on graphical tools. While most — if not all — of these graphical tools would be usable as individually-launched applications with their X11 tunneled through SSH back to the workstations they're using, that hasn't been enough for some of them:

• Many don't have X11 servers installed on their laptops
  • I usually like to point BYOD Windows users to Cygwin/X, MobaXterm, Xming, VcXsrv and the corporate-issued Windows users to contact their employers and ask that they add any one of the commercial Xserver offerings to their laptops
  • Though, given the number of Macintosh users in their ranks, they have Xservers, but it seems like they don't quite understand that fact: In either case, most don't seem to understand that the "easy button" solution is to add:

Host *
  ForwardAgent true

To their ${HOME}/.ssh/config files. And that doing so allows them to SSH to their development-host and, by executing <GRAPHICAL_UTILITY> on the remote server, it will cause the utility to magically appear on their laptop.

Even once you show them the magic of X11 forwarding, many will whine "I don't want to have to have a terminal open just to executed programs, I want the entire remote desktop so I can just use the launchers." Result, I've been having to help Linux neophytes install the full Gnome desktop on top of our standard AMIs and figuring out how to access them.

Our standard AMIs are RHEL- and CentOS-based have little more on them than the @Core RPM-group. The AMIs also have boot-EBSes that are as small as we could make them and meet the server security-requirements that require the AMIs' filesystems to be carved up into prescribe partitions. These initially led to several common questions:

1. "Can you create new AMIs that have enough room for us to install the Gnome desktop onto"; and
2. "Can you create an AMI with the Gnome-desktop preinstalled".

The answer to both has always been, "no, but if you follow the FAQ on how to expand the disk at launch-time, you'll have plenty of space for installing the Gnome desktop yourself".

Unfortunately, with the sudden proliferation of people building themselves graphical development EC2s, our various customers' security assessors have taken notice. That means that our (headless) server-oriented automated-hardening tools are not accounting for the now Gnome-enabled "desktops". By itself, not a problem, but different assessors have different demands around banners.

For some assessors, simply painting the contents of /etc/issue on the Gnome login screen's root window is sufficient. Fortunately, the Gnome project provides instructions that are also somewhere in the neighborhood of "dead-easy to do". Once done, you have a login screen that looks something like:

Unfortunately, some assessors insist that your consent banner must be a pop-up that is displayed prior to the would-be-user being allowed to enter their username or password. Meeting this requirement is a skosh more-involved. Instead of doing the above Gnome mods, one needs to do:

1. Move the existing /etc/gdm/Init/Default file contents aside (e.g., mv /etc/gdm/Init/Default{,-DIST})
2. Install a new /etc/gdm/Init/Default file (and use Zenity to create a create a dialogue-box from the /etc/issue file) with contents similar to:

/usr/bin/zenity --text-info --width=700 --height=300 \
   --title="Security Message" --filename=/etc/issue

1. Restart the GDM service (e.g., systemctl restart gdm) Doing this results in production of a pre-authentication pop-up similar to the following:

If you want something marginally fancier, you can install yad (from EPEL). If using yad, changing your /etc/gdm/Init/Default contents to something like:

/usr/bin/yad \
--center \
--buttons-layout=center \
--button=OK:0 \
--no-escape \
--fontname="Monospace Regular 10" \
--fore tomato4 \
--text-info \
--width=700 \
--height=300 \
--wrap \
--title="Security Message" \
--filename=/etc/issue

Will produce a screen like:

Primary differences being ability to set the text-color and get rid of the extraneous "Cancel" button (and center the "Ok" button).