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

David Smith dsmith at eclipse.ncsc.mil
Tue Nov 27 13:41:48 UTC 2012


Agreed.  The criteria by which we're supposed to be deciding which 
things are important (and their respective degrees of importance) points 
directly to impact on confidentiality/integrity/availability.  I'm not 
seeing how the login banner addresses any of those areas.

On 11/25/2012 07:19 PM, Jeffrey Blank wrote:
> 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 <mailto: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
>     <mailto:scap-security-guide-bounces at lists.fedorahosted.org>
>     [scap-security-guide-bounces at lists.fedorahosted.org
>     <mailto:scap-security-guide-bounces at lists.fedorahosted.org>] on
>     behalf of Shawn Wells [shawn at redhat.com <mailto:shawn at redhat.com>]
>     Sent: Thursday, October 25, 2012 9:33 PM
>     To: scap-security-guide at lists.fedorahosted.org
>     <mailto: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
>     <mailto: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/20121127/1f19c34f/attachment.html>


More information about the scap-security-guide mailing list