Alternate way to to graphical login banner, with logging of acceptence

Brian Peake PEAKE at HIPKLLC.COM
Mon Nov 26 13:09:11 UTC 2012


For whatever it is worth (not much). I have been using zenity to do my login
banner for GDM on my RHEL6 build.. For example;
http://slashsarc.com/2011/07/rhel-6-login-banners/

I have also the short DoD notice (I have read & consentĀŠ) in the GDM login
window as the full banner is cramped and does not fit in certain
resolutions.

Very Respectfully,
Brian Peake
From:  Jeffrey Blank <scapafterhours at gmail.com>
Reply-To:  <scap-security-guide at lists.fedorahosted.org>
Date:  Sun, 25 Nov 2012 19:19:02 -0500
To:  <scap-security-guide at lists.fedorahosted.org>
Subject:  Re: Alternate way to to graphical login banner, with logging of
acceptence

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 at 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 at lists.fedorahosted.org
> [scap-security-guide-bounces at lists.fedorahosted.org] on behalf of Shawn Wells
> [shawn at redhat.com]
> Sent: Thursday, October 25, 2012 9:33 PM
> To: scap-security-guide at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

_______________________________________________ scap-security-guide mailing
list scap-security-guide at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20121126/cc34b79a/attachment.html>


More information about the scap-security-guide mailing list