All this trouble to achieve a separate click for banner consent is such an
absurd misprioritization of security resources, and it's painful to watch.
Always remember that this sort of security/policy theatre competes with
patching systems and reviewing logs.
Two points:
1)
I continue to await any evidence that login banners have ever been a
decisive factor in any sort of legal proceeding.
2)
If a vendor's product cannot be trivially configured to ask for a separate
click for banner acceptance out-of-the-box, then this should simply be
documented and we should all move on. It can become an accepted "risk"
(ha, ha) for use of the product.
This is a far smarter move than trying to add or maintain even more
software. But this has been an excellent discussion, and highly
illustrative with regard to how well-intended policies result in devotion
of resources.
On Fri, Oct 26, 2012 at 6:50 AM, Robert Sanders <rsanders(a)trustedcs.com>wrote:
Pretty close. User sits down at console, sees authentication screen
with
short blat about needing to agree to the 'consent to monitor'. User
authenticates, X starts up and the first thing they see *after* that is the
full login banner (with either an acknowledgement button or a accept/deny -
depending on guideline). User's selection is logged, and either proceeds
with the remainder of the login or returns to the authentication screen
depending on their choice.
There is some changes at the front end on *how* the first message is
displayed (what we call the pre-login banner), but the user is presented
the 'official' login banner (IE - the DoD Banner) pretty early in the
Session setup. Doing it this way they know they'll have to see the banner,
they login, are presented with the banner, and have to agree to it before
the login continues.
-Rob
________________________________________
From: scap-security-guide-bounces(a)lists.fedorahosted.org [
scap-security-guide-bounces(a)lists.fedorahosted.org] on behalf of Shawn
Wells [shawn(a)redhat.com]
Sent: Thursday, October 25, 2012 9:33 PM
To: scap-security-guide(a)lists.fedorahosted.org
Subject: Re: Alternate way to to graphical login banner, with
logging of acceptence
On 10/25/12 3:29 PM, Robert Sanders wrote:
Greetings all,
As I mentioned in the conference call, we have a slightly different way
of doing the login banner that also gets the user's acknowledgement sent
to /var/log/secure (or the equivalent). I should note that our tool helps
with remediating a box against several different guidelines. Hence we
tried to find as 'simple' a way to do this as possible, without large
banners looking seriously cramped (IE - cram the full DoD login banner into
the default authentication dialog on a small screen). We also tried to
support both pure Gnome (GDM) and KDE (kdm). I'll handwave through the
details (ping me if you'd like more info).
Basically we add wording to the main login with text along the lines of:
All users will be required to read and accept a 'Consent to
Monitor' statement before being allowed to login.
The response will be logged.
This text fits nicely on most of the OS's we support, and is shown on
every graphical login attempt on the main authentication display.
Currently for GDM on Fedora/RHEL6 we make these changes to
/apps/gdm/simple-greeter/*, most of the other Linux boxes we'll change the
/etc/X11/gdm/gdm.conf or /etc/gdm/custom.conf file instead. For KDM it all
goes to /usr/share/config/kdm/kdmrc.
To display the actual required login banner we tweak the
/etc/X11/gdm/PreSession/Default (Solaris), /etc/X11/xdm/Xsession (RH4), or
/etc/X11/xinit/Xsession (everyone else) file to call a script that uses
zenity or kdialog (use first one found) to display the text of the banner.
Since we do support other guidelines that may just require notification,
we have our dialog may just have an acknowledgement button or an explicit
accept/deny button. The user's response is logged using the first of
/usr/sbin/logger, /sbin/logger, /usr/bin/logger, or /bin/logger with
authpriv.notice. Obviously if the user hits deny we fail out back to the
authentication screen.
Disadvantages : change to expected login procedure/alternate login
mananger, extra script on login
Advantages : acknowledgement tied that the login banner was
accepted/read to a particular user, better framing of potentially large
banner text
I'm interested in the concept of logging the user acceptance, but I'm not
sure I understand the process your users follow. From what I gather a user
attempts to login via GUI, is presented with the standard DoD banner, then
is presented with your custom prompt of which logs their response?
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide