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.
I continue to await any evidence that login banners have ever been a
decisive factor in any sort of legal proceeding.
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(a)trustedcs.com <mailto:email@example.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.
behalf of Shawn Wells [shawn(a)redhat.com <mailto:firstname.lastname@example.org>]
Sent: Thursday, October 25, 2012 9:33 PM
Subject: Re: Alternate way to to graphical login banner,
with logging of acceptence
On 10/25/12 3:29 PM, Robert Sanders wrote:
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
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 mailing list