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

Jeffrey Blank scapafterhours at gmail.com
Mon Nov 26 00:19:02 UTC 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20121125/dd71c7c2/attachment.html>


More information about the scap-security-guide mailing list