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