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
Sincerely, Rob Sanders =========================== Rob Sanders Sr. Secure Systems Engineer Raytheon Trusted Computer Solutions 12950 Worldgate Drive, Suite 600 Herndon, Virginia 20170 Security Blanket Support: 1-866-230-1317 Security Blanket Email: SecurityBlanket@TrustedCS.com Office: 703-896-4762 Fax: 703-318-5041 Email: RSanders@TrustedCS.com
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?
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@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Shawn Wells [shawn@redhat.com] Sent: Thursday, October 25, 2012 9:33 PM To: scap-security-guide@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?
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@trustedcs.comwrote:
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@lists.fedorahosted.org [ scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Shawn Wells [shawn@redhat.com] Sent: Thursday, October 25, 2012 9:33 PM To: scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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@gmail.com Reply-To: scap-security-guide@lists.fedorahosted.org Date: Sun, 25 Nov 2012 19:19:02 -0500 To: scap-security-guide@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@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@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Shawn Wells [shawn@redhat.com] Sent: Thursday, October 25, 2012 9:33 PM To: scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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:
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@trustedcs.com mailto:rsanders@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@lists.fedorahosted.org <mailto:scap-security-guide-bounces@lists.fedorahosted.org> [scap-security-guide-bounces@lists.fedorahosted.org <mailto:scap-security-guide-bounces@lists.fedorahosted.org>] on behalf of Shawn Wells [shawn@redhat.com <mailto:shawn@redhat.com>] Sent: Thursday, October 25, 2012 9:33 PM To: scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@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@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 11/27/12 8:41 AM, David Smith wrote:
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.
Then why do we have an entire section on login banners, mapped to some 16 different government policies? http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide...
Current RHEL-based login banners do not specifically log user acceptance, and to mitigate that most accepted banner prose includes language around "by continuing past this point.... you accept." Legal people have found this to be perfectly acceptable and for that reason it appears we can move on (which it appears David and Jeff are getting at).
With that said, should users want RHEL to natively log such acceptances, they should put in an RFE through their vendor rep. I'll be happy to assist people with putting in RFEs should they not know who their Red Hat contact is.
scap-security-guide@lists.fedorahosted.org
-
Brian Peake -
David Smith -
Jeffrey Blank -
Robert Sanders -
Shawn Wells