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