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 to be carved up into 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, 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 with contents similar to:

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

   Which uses Zenity to create a create a dialogue-box from the /etc/issue file.
   
3. 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).

Punishing Network Performance

Recently, I took delivery of a new laptop. My old laptop was rolling up on five years old, was still running Windows 7 and had less than 1GiB of free disk space. So, "it was time".

At any rate, the new laptop runs Windows 10 Pro. One of the nice things about this is that, because MicroSoft makes Hyper-V available for free for my OS, I no longer have to deal with VirtualBox (or any add-on virtualization solution, for that matter). It means I'm free of the endless parade of "you must reboot to install new VirtualBox drivers" that pretty much caused me to stop with local virtualization on my prior laptop.

One of the nice things with virtualization is that it lets me run Linux, locally. While WSL/WSL2 show promise, they aren't quite there yet. Similarly, I'm not super chuffed that Docker Desktop for Windows requires me to run Docker as root. So, my Linux VM is an EL8 host that I am able to run PodMan on (and able to run my containers as an unprivileged user within that VM).

That said, most of the "how to run Linux on Hyper-V on Windows 10" guides I found resulted in my networking getting completely and totally jacked up. When not jacked up, my Internet connection looks like:

However, after initially booting my CentOS VM, I noticed that my yum downloads were running stoopid-slow. I assumed the problem was constrained to the VM. However, being detail-oriented, I checked my OS's network speed. It was, uh, "not good". I was getting less than 4Mbps down and about 0.2Mbps up. I also found that, if I rebooted my system, my download speeds would come back, but my uploads still sucked. Lastly, I found that if I wholly de-configured Hyper-V, my networking returned to normal.

Sleuthing time.

I hit the Googs and everyone is saying "this is a known issue: you can fix it by changing your NIC settings." Unfortunately, the mentioned settings weren't available in my NIC. Dunno if it's because I'm using WiFi or what. All I know is that it was looking like my choices were going to be "have good Internet speeds or have Linux on Hyper-V".

I'm not real keen on such choices. So, I kept digging – eventually getting to the point where I went beyond the first page of results. Ultimately, I found an answer on one of the StackExchange forums. Interestingly, the answer I found wasn't even marked as the "best answer". Had I not read through all the responses on one thread, I wouldn't even have found it.

At any rate, the fix was to not use my NIC in bridged mode at all. Instead, I needed to ignore all the top-match guides' instructions to use an "External" interface (which puts your NIC into bridged mode) and, instead, use an "Internal" interface ...and then set up connection-sharing, allowing my private vSwitch to share (rather than bridge) through my WiFi adapter. As soon as I made that change, my speeds came back.