[PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
Patch summary: * check for 'nousb' argument on kernel command line in /etc/grub.conf within the bootloader_nousb_argument check in a case-insensitive way * update comments where appropriate * add test attestation timestamp * replace path + filename ind construct with filepath one
Testing report: * Tested on RHEL-6. Works fine.
Please review.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
- check for 'nousb' argument on kernel command line in /etc/grub.conf within the bootloader_nousb_argument check in a case-insensitive way
- update comments where appropriate
- add test attestation timestamp
- replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
On Apr 16, 2014, at 7:59 PM, Shawn Wells <shawn@redhat.commailto:shawn@redhat.com> wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary: * check for 'nousb' argument on kernel command line in /etc/grub.conf within the bootloader_nousb_argument check in a case-insensitive way * update comments where appropriate * add test attestation timestamp * replace path + filename ind construct with filepath one
Testing report: * Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
On Apr 16, 2014, at 8:06 PM, Kayse, Josh <Joshua.Kayse@gtri.gatech.edumailto:Joshua.Kayse@gtri.gatech.edu> wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells <shawn@redhat.commailto:shawn@redhat.com> wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary: * check for 'nousb' argument on kernel command line in /etc/grub.conf within the bootloader_nousb_argument check in a case-insensitive way * update comments where appropriate * add test attestation timestamp * replace path + filename ind construct with filepath one
Testing report: * Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
-josh
On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh <Joshua.Kayse@gtri.gatech.edu mailto:Joshua.Kayse@gtri.gatech.edu> wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells <shawn@redhat.com mailto:shawn@redhat.com> wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
- check for 'nousb' argument on kernel command line in /etc/grub.conf within the bootloader_nousb_argument check in a case-insensitive way
- update comments where appropriate
- add test attestation timestamp
- replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
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
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
-josh
Thanks for that link!
Ack to Jan's patch.
Just out of curiosity, is adding nousb to the grub command line actually feasible for enforcement?
I can't remember the last time I used a system where I didn't need a USB keyboard at some point (can you even buy server class systems with PS/2 support any more?)
Trevor
On Wed, Apr 16, 2014 at 8:23 PM, Shawn Wells shawn@redhat.com wrote:
On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh Joshua.Kayse@gtri.gatech.edu wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells shawn@redhat.com wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
- check for 'nousb' argument on kernel command line in /etc/grub.conf within the bootloader_nousb_argument check in a case-insensitive way
- update comments where appropriate
- add test attestation timestamp
- replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
-josh
Thanks for that link!
Ack to Jan's patch.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 4/17/14, 5:11 AM, Trevor Vaughan wrote:
Just out of curiosity, is adding nousb to the grub command line actually feasible for enforcement?
Virtual machines.
I can't remember the last time I used a system where I didn't need a USB keyboard at some point (can you even buy server class systems with PS/2 support any more?)
Complete agreement, and acknowledgement in the rule's description:
/*WARNING:*Disabling all kernel support for USB will cause problems for systems with USB-based keyboards, mice, or printers. This configuration is infeasible for systems which require USB devices, which is common./
Patches welcome which clarify/balance physical deployments vs VMs.
Virtual machines -> Touche! I always forget about that.
Are we going to have something like Facter on the system to be able to discover if they are virtual or not?
If we could do that, we might stand a shot but without it, I don't know of a good way of doing this across a VM cluster in terms of checking with OVAL rules.
Trevor
On Thu, Apr 17, 2014 at 2:57 PM, Shawn Wells shawn@redhat.com wrote:
On 4/17/14, 5:11 AM, Trevor Vaughan wrote:
Just out of curiosity, is adding nousb to the grub command line actually feasible for enforcement?
Virtual machines.
I can't remember the last time I used a system where I didn't need a USB keyboard at some point (can you even buy server class systems with PS/2 support any more?)
Complete agreement, and acknowledgement in the rule's description:
*WARNING: Disabling all kernel support for USB will cause problems for systems with USB-based keyboards, mice, or printers. This configuration is infeasible for systems which require USB devices, which is common.*
Patches welcome which clarify/balance physical deployments vs VMs.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 4/17/14, 12:17 PM, Trevor Vaughan wrote:
Virtual machines -> Touche! I always forget about that.
Are we going to have something like Facter on the system to be able to discover if they are virtual or not?
If we can finagle RHT to ship it natively in RHEL, sure :)
If we could do that, we might stand a shot but without it, I don't know of a good way of doing this across a VM cluster in terms of checking with OVAL rules.
I thought about pulling info from /sys/class/dmi/id/sys_vendor, however that would (theoretically) require managing a list of vendor return codes. Ain't nobody got time for that.
We have a mix a systems to which some require USB and some do not. While it’s not feasible to know the need of every system when applying this requirement, I have found some logic that seems to work:
USB_DEVICE=$(grep 'Product=' /proc/bus/usb/devices | egrep -ic '(ps2 to usb adapter|keyboard|kvm|sc reader)')
If [ $USB_DEVICE = 0 ]; then DO SOME ACTION fi
The above will check for a USB keyboard, a PS2 to USB adapter (needed for a USB keyboard in some cases), a USB KVM, and a CAC reader (only approved versions are USB).
It may be useful to add that logic to your fix.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trevor Vaughan Sent: Thursday, April 17, 2014 7:11 AM To: SCAP Security Guide Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
Just out of curiosity, is adding nousb to the grub command line actually feasible for enforcement?
I can't remember the last time I used a system where I didn't need a USB keyboard at some point (can you even buy server class systems with PS/2 support any more?)
Trevor
On Wed, Apr 16, 2014 at 8:23 PM, Shawn Wells shawn@redhat.commailto:shawn@redhat.com> wrote: On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh Joshua.Kayse@gtri.gatech.edumailto:Joshua.Kayse@gtri.gatech.edu> wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells shawn@redhat.commailto:shawn@redhat.com> wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
* check for 'nousb' argument on kernel command line in /etc/grub.conf
within the bootloader_nousb_argument check in a case-insensitive way
* update comments where appropriate
* add test attestation timestamp
* replace path + filename ind construct with filepath one
Testing report:
* Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
a trailing = on the name of any parameter states that that parameter will
be entered as an environment variable, whereas its absence indicates that
it will appear as a kernel argument readable via /proc/cmdline by programs
running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works? _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
-josh
Thanks for that link!
Ack to Jan's patch.
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.commailto:tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.com sent at 2014-04-17 15:20:52 is confidential and may be legally privileged. It is intended solely for use by scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
So, wouldn't this be better approached as a udev requirement?
I've been avoiding udev for ages just because I don't want to get pummelled over the complexity but this is exactly what it can do, isn't it?
Instead of saying that all USB keyboards are allowed, if you know your vendor, then you say that exactly the keyboards you expect to be on your systems are allowed, etc...
I understand that no USB at the kernel level is safer but this is pushing my 'usability vs security' balance warnings.
I.e. if, for whatever reason, I HAVE to use something USB on a system that can't have any downtime, you'd better believe that I'm going to leave usb on in the kernel. And, realistically, isn't that most of the systems you're trying to protect the most?
http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devi...
As for VMs, if I wanted to plug a USB device into a VM, I would need administrative access to the physical host to be able to attach the virtual device. If that's the case it doesn't really matter since I can pretty much do whatever I like to the VM (including copying its memory and disk) and not worry about it.
Yes, I know, whining and no patches....but I'm trying to have constructive whining ;-).
Thanks,
Trevor
On Thu, Apr 17, 2014 at 3:20 PM, Trey Henefield < trey.henefield@ultra-ats.com> wrote:
We have a mix a systems to which some require USB and some do not. While it’s not feasible to know the need of every system when applying this requirement, I have found some logic that seems to work:
USB_DEVICE=$(grep 'Product=' /proc/bus/usb/devices | egrep -ic '(ps2 to usb adapter|keyboard|kvm|sc reader)')
If [ $USB_DEVICE = 0 ]; then
DO SOME ACTIONfi
The above will check for a USB keyboard, a PS2 to USB adapter (needed for a USB keyboard in some cases), a USB KVM, and a CAC reader (only approved versions are USB).
It may be useful to add that logic to your fix.
Best regards,
Trey Henefield, CISSP
Senior IAVA Engineer
Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450
www.ultra-ats.com
*From:* scap-security-guide-bounces@lists.fedorahosted.org [mailto: scap-security-guide-bounces@lists.fedorahosted.org] *On Behalf Of *Trevor Vaughan *Sent:* Thursday, April 17, 2014 7:11 AM *To:* SCAP Security Guide *Subject:* Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
Just out of curiosity, is adding nousb to the grub command line actually feasible for enforcement?
I can't remember the last time I used a system where I didn't need a USB keyboard at some point (can you even buy server class systems with PS/2 support any more?)
Trevor
On Wed, Apr 16, 2014 at 8:23 PM, Shawn Wells shawn@redhat.com wrote:
On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh Joshua.Kayse@gtri.gatech.edu wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells shawn@redhat.com wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
check for 'nousb' argument on kernel command line in /etc/grub.conf
within the bootloader_nousb_argument check in a case-insensitive way
update comments where appropriate
add test attestation timestamp
replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
a trailing = on the name of any parameter states that that parameter will
be entered as an environment variable, whereas its absence indicates that
it will appear as a kernel argument readable via /proc/cmdline by programs
running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
-josh
Thanks for that link!
Ack to Jan's patch.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
*Disclaimer* The information contained in this communication from * trey.henefield@ultra-ats.com trey.henefield@ultra-ats.com * sent at 2014-04-17 15:20:52 is private and may be legally privileged or export controlled. It is intended solely for use by * scap-security-guide@lists.fedorahosted.org scap-security-guide@lists.fedorahosted.org * and others authorized to receive it. If you are not * scap-security-guide@lists.fedorahosted.org scap-security-guide@lists.fedorahosted.org * you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Implementing a more generic approach allows flexibility for other systems and environments. Since the SSG is aimed to support a large variety of environments, it seems more appropriate to take the generic approach as opposed to a UDEV approach for a specific device. Just my 2 cents.
I have shared plenty of grief in applying this requirement in different environments. This is my lessons learned.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trevor Vaughan Sent: Thursday, April 17, 2014 2:38 PM To: SCAP Security Guide Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
So, wouldn't this be better approached as a udev requirement? I've been avoiding udev for ages just because I don't want to get pummelled over the complexity but this is exactly what it can do, isn't it?
Instead of saying that all USB keyboards are allowed, if you know your vendor, then you say that exactly the keyboards you expect to be on your systems are allowed, etc...
I understand that no USB at the kernel level is safer but this is pushing my 'usability vs security' balance warnings. I.e. if, for whatever reason, I HAVE to use something USB on a system that can't have any downtime, you'd better believe that I'm going to leave usb on in the kernel. And, realistically, isn't that most of the systems you're trying to protect the most?
http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devi... As for VMs, if I wanted to plug a USB device into a VM, I would need administrative access to the physical host to be able to attach the virtual device. If that's the case it doesn't really matter since I can pretty much do whatever I like to the VM (including copying its memory and disk) and not worry about it. Yes, I know, whining and no patches....but I'm trying to have constructive whining ;-). Thanks,
Trevor
On Thu, Apr 17, 2014 at 3:20 PM, Trey Henefield <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> wrote:
We have a mix a systems to which some require USB and some do not. While it’s not feasible to know the need of every system when applying this requirement, I have found some logic that seems to work:
USB_DEVICE=$(grep 'Product=' /proc/bus/usb/devices | egrep -ic '(ps2 to usb adapter|keyboard|kvm|sc reader)')
If [ $USB_DEVICE = 0 ]; then DO SOME ACTION fi
The above will check for a USB keyboard, a PS2 to USB adapter (needed for a USB keyboard in some cases), a USB KVM, and a CAC reader (only approved versions are USB).
It may be useful to add that logic to your fix.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647 Fax: +1 512 327 8043tel:%2B1%20512%20327%208043 Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450
www.ultra-ats.comhttp://www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trevor Vaughan Sent: Thursday, April 17, 2014 7:11 AM To: SCAP Security Guide Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
Just out of curiosity, is adding nousb to the grub command line actually feasible for enforcement?
I can't remember the last time I used a system where I didn't need a USB keyboard at some point (can you even buy server class systems with PS/2 support any more?)
Trevor
On Wed, Apr 16, 2014 at 8:23 PM, Shawn Wells <shawn@redhat.commailto:shawn@redhat.com> wrote: On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh <Joshua.Kayse@gtri.gatech.edumailto:Joshua.Kayse@gtri.gatech.edu> wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells <shawn@redhat.commailto:shawn@redhat.com> wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
* check for 'nousb' argument on kernel command line in /etc/grub.conf
within the bootloader_nousb_argument check in a case-insensitive way
* update comments where appropriate
* add test attestation timestamp
* replace path + filename ind construct with filepath one
Testing report:
* Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
a trailing = on the name of any parameter states that that parameter will
be entered as an environment variable, whereas its absence indicates that
it will appear as a kernel argument readable via /proc/cmdline by programs
running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works? _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
-josh
Thanks for that link!
Ack to Jan's patch.
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699tel:%28410%29%20541-6699 tvaughan@onyxpoint.commailto:tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2014-04-17 15:20:52 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.commailto:tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Udev is system agnostic and works like a firewall instead of a sledgehammer. Deny all, allow as approved.
nousb is a sledgehammer, you can't turn it back on without a reboot.
I'm wanting to allow <Vendor> keyboards of type X, not all keyboards that may have who knows what built into them. Udev lets me do this but nousb doesn't.
As far as I can tell, udev appears to be supported in almost all modern Linux distros and, if it's not, you can always sledgehammer the system.
That said, I'm certainly happy for the discussion since it's what it takes to move things forward (in whatever direction).
Thanks,
Trevor
On Thu, Apr 17, 2014 at 3:49 PM, Trey Henefield < trey.henefield@ultra-ats.com> wrote:
Implementing a more generic approach allows flexibility for other systems and environments. Since the SSG is aimed to support a large variety of environments, it seems more appropriate to take the generic approach as opposed to a UDEV approach for a specific device. Just my 2 cents.
I have shared plenty of grief in applying this requirement in different environments. This is my lessons learned.
Best regards,
Trey Henefield, CISSP
Senior IAVA Engineer
Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450
www.ultra-ats.com
*From:* scap-security-guide-bounces@lists.fedorahosted.org [mailto: scap-security-guide-bounces@lists.fedorahosted.org] *On Behalf Of *Trevor Vaughan *Sent:* Thursday, April 17, 2014 2:38 PM
*To:* SCAP Security Guide *Subject:* Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
So, wouldn't this be better approached as a udev requirement?
I've been avoiding udev for ages just because I don't want to get pummelled over the complexity but this is exactly what it can do, isn't it?
Instead of saying that all USB keyboards are allowed, if you know your vendor, then you say that exactly the keyboards you expect to be on your systems are allowed, etc...
I understand that no USB at the kernel level is safer but this is pushing my 'usability vs security' balance warnings.
I.e. if, for whatever reason, I HAVE to use something USB on a system that can't have any downtime, you'd better believe that I'm going to leave usb on in the kernel. And, realistically, isn't that most of the systems you're trying to protect the most?
http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devi...
As for VMs, if I wanted to plug a USB device into a VM, I would need administrative access to the physical host to be able to attach the virtual device. If that's the case it doesn't really matter since I can pretty much do whatever I like to the VM (including copying its memory and disk) and not worry about it.
Yes, I know, whining and no patches....but I'm trying to have constructive whining ;-).
Thanks,
Trevor
On Thu, Apr 17, 2014 at 3:20 PM, Trey Henefield < trey.henefield@ultra-ats.com> wrote:
We have a mix a systems to which some require USB and some do not. While it’s not feasible to know the need of every system when applying this requirement, I have found some logic that seems to work:
USB_DEVICE=$(grep 'Product=' /proc/bus/usb/devices | egrep -ic '(ps2 to usb adapter|keyboard|kvm|sc reader)')
If [ $USB_DEVICE = 0 ]; then
DO SOME ACTIONfi
The above will check for a USB keyboard, a PS2 to USB adapter (needed for a USB keyboard in some cases), a USB KVM, and a CAC reader (only approved versions are USB).
It may be useful to add that logic to your fix.
Best regards,
Trey Henefield, CISSP
Senior IAVA Engineer
Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450
www.ultra-ats.com
*From:* scap-security-guide-bounces@lists.fedorahosted.org [mailto: scap-security-guide-bounces@lists.fedorahosted.org] *On Behalf Of *Trevor Vaughan *Sent:* Thursday, April 17, 2014 7:11 AM *To:* SCAP Security Guide *Subject:* Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
Just out of curiosity, is adding nousb to the grub command line actually feasible for enforcement?
I can't remember the last time I used a system where I didn't need a USB keyboard at some point (can you even buy server class systems with PS/2 support any more?)
Trevor
On Wed, Apr 16, 2014 at 8:23 PM, Shawn Wells shawn@redhat.com wrote:
On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh Joshua.Kayse@gtri.gatech.edu wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells shawn@redhat.com wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
check for 'nousb' argument on kernel command line in /etc/grub.conf
within the bootloader_nousb_argument check in a case-insensitive way
update comments where appropriate
add test attestation timestamp
replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
a trailing = on the name of any parameter states that that parameter will
be entered as an environment variable, whereas its absence indicates that
it will appear as a kernel argument readable via /proc/cmdline by programs
running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
-josh
Thanks for that link!
Ack to Jan's patch.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
*Disclaimer* The information contained in this communication from *trey.henefield@ultra-ats.com trey.henefield@ultra-ats.com *sent at 2014-04-17 15:20:52 is private and may be legally privileged or export controlled. It is intended solely for use by *scap-security-guide@lists.fedorahosted.org scap-security-guide@lists.fedorahosted.org *and others authorized to receive it. If you are not *scap-security-guide@lists.fedorahosted.org scap-security-guide@lists.fedorahosted.org *you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 4/17/14, 12:54 PM, Trevor Vaughan wrote:
Udev is system agnostic and works like a firewall instead of a sledgehammer. Deny all, allow as approved.
nousb is a sledgehammer, you can't turn it back on without a reboot.
I'm wanting to allow <Vendor> keyboards of type X, not all keyboards that may have who knows what built into them. Udev lets me do this but nousb doesn't.
As far as I can tell, udev appears to be supported in almost all modern Linux distros and, if it's not, you can always sledgehammer the system.
That said, I'm certainly happy for the discussion since it's what it takes to move things forward (in whatever direction).
Reviewed the link you sent over (http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devi...). Specifically:
#Script by Adrian Crenshaw #With info from Michael Miller, Inaky Perez-Gonzalez and VMWare
#By default, disable it. #ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'echo 0
/sys$DEVPATH/authorized'"
ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'for host in /sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default; done'"
#Enable hub devices. There may be a better way than this. ACTION=="add", ATTR{bDeviceClass}=="09", RUN+="/bin/sh -c 'echo 1
/sys$DEVPATH/authorized'"
#Other things to enable ACTION=="add", ATTR{idVendor}=="046d", ATTR{idProduct}=="0809", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'" ACTION=="add", ATTR{serial}=="078606B90DD3", RUN+="/bin/sh -c 'echo 1
/sys$DEVPATH/authorized'"
ACTION=="add", ATTR{product}=="802.11 n WLAN", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'" #ACTION=="add", ATTR{idVendor}=="413c", ATTR{idProduct}=="2106", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'"
My first reaction was to say "If 'cat $host/authorized_default == 0' or nousb, then pass || if /sys$DEVPATH/authorized != *, pass"
It's laughable... but I don't own a USB device. Not even a storage token. Since you're starting the conversation, could you test such a system configuration ou and see if such an approach is even sane?
The authorized and authorized_default files are action toggles.
It looks like you need to check /sys/bus/usb/devices/usb*/authorized_default == 1 for a failure case.
If those are all '0', then USB is not authorized for any system devices by default.
Don't have a chance to test right now but I can play more later.
https://www.kernel.org/doc/Documentation/usb/authorization.txt
Trevor
On Thu, Apr 17, 2014 at 11:51 PM, Shawn Wells shawn@redhat.com wrote:
On 4/17/14, 12:54 PM, Trevor Vaughan wrote:
Udev is system agnostic and works like a firewall instead of a sledgehammer. Deny all, allow as approved.
nousb is a sledgehammer, you can't turn it back on without a reboot.
I'm wanting to allow <Vendor> keyboards of type X, not all keyboards that may have who knows what built into them. Udev lets me do this but nousb doesn't.
As far as I can tell, udev appears to be supported in almost all modern Linux distros and, if it's not, you can always sledgehammer the system.
That said, I'm certainly happy for the discussion since it's what it takes to move things forward (in whatever direction).
Reviewed the link you sent over ( http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devi...). Specifically:
#Script by Adrian Crenshaw #With info from Michael Miller, Inaky Perez-Gonzalez and VMWare
#By default, disable it. #ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'echo 0
/sys$DEVPATH/authorized'"
ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'for host in /sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default; done'"
#Enable hub devices. There may be a better way than this. ACTION=="add", ATTR{bDeviceClass}=="09", RUN+="/bin/sh -c 'echo 1
/sys$DEVPATH/authorized'"
#Other things to enable ACTION=="add", ATTR{idVendor}=="046d", ATTR{idProduct}=="0809", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'" ACTION=="add", ATTR{serial}=="078606B90DD3", RUN+="/bin/sh -c 'echo 1
/sys$DEVPATH/authorized'"
ACTION=="add", ATTR{product}=="802.11 n WLAN", RUN+="/bin/sh -c 'echo 1
/sys$DEVPATH/authorized'"
#ACTION=="add", ATTR{idVendor}=="413c", ATTR{idProduct}=="2106", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'"
My first reaction was to say "If 'cat $host/authorized_default == 0' or nousb, then pass || if /sys$DEVPATH/authorized != *, pass"
It's laughable... but I don't own a USB device. Not even a storage token. Since you're starting the conversation, could you test such a system configuration ou and see if such an approach is even sane?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I put this (attached) together a while back to configure USB device whitelisting through udev. If it helps, great. If not, please pardon the intrusion.
Brian
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trevor Vaughan Sent: Friday, April 18, 2014 11:47 AM To: SCAP Security Guide Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
The authorized and authorized_default files are action toggles.
It looks like you need to check /sys/bus/usb/devices/usb*/authorized_default == 1 for a failure case.
If those are all '0', then USB is not authorized for any system devices by default.
Don't have a chance to test right now but I can play more later.
https://www.kernel.org/doc/Documentation/usb/authorization.txt
Trevor
On Thu, Apr 17, 2014 at 11:51 PM, Shawn Wells <shawn@redhat.commailto:shawn@redhat.com> wrote: On 4/17/14, 12:54 PM, Trevor Vaughan wrote: Udev is system agnostic and works like a firewall instead of a sledgehammer. Deny all, allow as approved. nousb is a sledgehammer, you can't turn it back on without a reboot. I'm wanting to allow <Vendor> keyboards of type X, not all keyboards that may have who knows what built into them. Udev lets me do this but nousb doesn't.
As far as I can tell, udev appears to be supported in almost all modern Linux distros and, if it's not, you can always sledgehammer the system. That said, I'm certainly happy for the discussion since it's what it takes to move things forward (in whatever direction).
Reviewed the link you sent over (http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devi...). Specifically:
#Script by Adrian Crenshaw #With info from Michael Miller, Inaky Perez-Gonzalez and VMWare
#By default, disable it. #ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'echo 0 >/sys$DEVPATH/authorized'" ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'for host in /sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default; done'"
#Enable hub devices. There may be a better way than this. ACTION=="add", ATTR{bDeviceClass}=="09", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'"
#Other things to enable ACTION=="add", ATTR{idVendor}=="046d", ATTR{idProduct}=="0809", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'" ACTION=="add", ATTR{serial}=="078606B90DD3", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'" ACTION=="add", ATTR{product}=="802.11 n WLAN", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'" #ACTION=="add", ATTR{idVendor}=="413c", ATTR{idProduct}=="2106", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'"
My first reaction was to say "If 'cat $host/authorized_default == 0' or nousb, then pass || if /sys$DEVPATH/authorized != *, pass"
It's laughable... but I don't own a USB device. Not even a storage token. Since you're starting the conversation, could you test such a system configuration ou and see if such an approach is even sane?
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.commailto:tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Brian,
That's a good usage example.Thanks for sharing!
Trevor
On Fri, Apr 18, 2014 at 3:22 PM, Roach, Brian Brian.Roach@ga.com wrote:
I put this (attached) together a while back to configure USB device whitelisting through udev. If it helps, great. If not, please pardon the intrusion.
Brian
*From:* scap-security-guide-bounces@lists.fedorahosted.org [ mailto:scap-security-guide-bounces@lists.fedorahosted.orgscap-security-guide-bounces@lists.fedorahosted.org] *On Behalf Of *Trevor Vaughan *Sent:* Friday, April 18, 2014 11:47 AM
*To:* SCAP Security Guide *Subject:* Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
The authorized and authorized_default files are action toggles.
It looks like you need to check /sys/bus/usb/devices/usb*/authorized_default == 1 for a failure case.
If those are all '0', then USB is not authorized for any system devices by default.
Don't have a chance to test right now but I can play more later.
https://www.kernel.org/doc/Documentation/usb/authorization.txt
Trevor
On Thu, Apr 17, 2014 at 11:51 PM, Shawn Wells shawn@redhat.com wrote:
On 4/17/14, 12:54 PM, Trevor Vaughan wrote:
Udev is system agnostic and works like a firewall instead of a sledgehammer. Deny all, allow as approved.
nousb is a sledgehammer, you can't turn it back on without a reboot.
I'm wanting to allow <Vendor> keyboards of type X, not all keyboards that may have who knows what built into them. Udev lets me do this but nousb doesn't.
As far as I can tell, udev appears to be supported in almost all modern Linux distros and, if it's not, you can always sledgehammer the system.
That said, I'm certainly happy for the discussion since it's what it takes to move things forward (in whatever direction).
Reviewed the link you sent over ( http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devi...). Specifically:
#Script by Adrian Crenshaw #With info from Michael Miller, Inaky Perez-Gonzalez and VMWare
#By default, disable it. #ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'echo 0
/sys$DEVPATH/authorized'"
ACTION=="add", SUBSYSTEMS=="usb", RUN+="/bin/sh -c 'for host in /sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default; done'"
#Enable hub devices. There may be a better way than this. ACTION=="add", ATTR{bDeviceClass}=="09", RUN+="/bin/sh -c 'echo 1
/sys$DEVPATH/authorized'"
#Other things to enable ACTION=="add", ATTR{idVendor}=="046d", ATTR{idProduct}=="0809", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'" ACTION=="add", ATTR{serial}=="078606B90DD3", RUN+="/bin/sh -c 'echo 1
/sys$DEVPATH/authorized'"
ACTION=="add", ATTR{product}=="802.11 n WLAN", RUN+="/bin/sh -c 'echo 1
/sys$DEVPATH/authorized'"
#ACTION=="add", ATTR{idVendor}=="413c", ATTR{idProduct}=="2106", RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'"
My first reaction was to say "If 'cat $host/authorized_default == 0' or nousb, then pass || if /sys$DEVPATH/authorized != *, pass"
It's laughable... but I don't own a USB device. Not even a storage token. Since you're starting the conversation, could you test such a system configuration ou and see if such an approach is even sane?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hi Trevor,
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, April 17, 2014 9:37:38 PM Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
So, wouldn't this be better approached as a udev requirement?
Checking /etc/grub.conf settings instead of udev ones has the advantage, the system to be scanned doesn't need to run (offline scan of provided VM image) to be able to decide if the system is configured properly.
I've been avoiding udev for ages just because I don't want to get pummelled over the complexity but this is exactly what it can do, isn't it?
Instead of saying that all USB keyboards are allowed, if you know your vendor, then you say that exactly the keyboards you expect to be on your systems are allowed, etc...
I understand that no USB at the kernel level is safer but this is pushing my 'usability vs security' balance warnings.
I.e. if, for whatever reason, I HAVE to use something USB on a system that can't have any downtime, you'd better believe that I'm going to leave usb on in the kernel. And, realistically, isn't that most of the systems you're trying to protect the most?
http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devi...
As for VMs, if I wanted to plug a USB device into a VM, I would need administrative access to the physical host to be able to attach the virtual device. If that's the case it doesn't really matter since I can pretty much do whatever I like to the VM (including copying its memory and disk) and not worry about it.
Yes, I know, whining and no patches....but I'm trying to have constructive whining ;-).
Thanks,
Trevor
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
On Thu, Apr 17, 2014 at 3:20 PM, Trey Henefield < trey.henefield@ultra-ats.com > wrote:
We have a mix a systems to which some require USB and some do not. While it’s not feasible to know the need of every system when applying this requirement, I have found some logic that seems to work:
USB_DEVICE=$(grep 'Product=' /proc/bus/usb/devices | egrep -ic '(ps2 to usb adapter|keyboard|kvm|sc reader)')
If [ $USB_DEVICE = 0 ]; then
DO SOME ACTION
fi
The above will check for a USB keyboard, a PS2 to USB adapter (needed for a USB keyboard in some cases), a USB KVM, and a CAC reader (only approved versions are USB).
It may be useful to add that logic to your fix.
Best regards,
Trey Henefield, CISSP
Senior IAVA Engineer
Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450
www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto: scap-security-guide-bounces@lists.fedorahosted.org ] On Behalf Of Trevor Vaughan Sent: Thursday, April 17, 2014 7:11 AM To: SCAP Security Guide Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
Just out of curiosity, is adding nousb to the grub command line actually feasible for enforcement?
I can't remember the last time I used a system where I didn't need a USB keyboard at some point (can you even buy server class systems with PS/2 support any more?)
Trevor
On Wed, Apr 16, 2014 at 8:23 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh < Joshua.Kayse@gtri.gatech.edu > wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
- check for 'nousb' argument on kernel command line in /etc/grub.conf
within the bootloader_nousb_argument check in a case-insensitive way
- update comments where appropriate
- add test attestation timestamp
- replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
-josh
Thanks for that link!
Ack to Jan's patch.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.com sent at 2014-04-17 15:20:52 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
If the SSG mandated that the value get set at boot time via a file in /etc/<upstart|systemd|something> wouldn't that be equally easy to validate offline?
You would want to do this anyway if you were going to use UDEV.
Trevor
On Fri, Apr 25, 2014 at 8:40 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
Hi Trevor,
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, April 17, 2014 9:37:38 PM Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line
argument in /etc/grub.conf within
bootloader_nousb_argument check case-insensitively
So, wouldn't this be better approached as a udev requirement?
Checking /etc/grub.conf settings instead of udev ones has the advantage, the system to be scanned doesn't need to run (offline scan of provided VM image) to be able to decide if the system is configured properly.
I've been avoiding udev for ages just because I don't want to get
pummelled
over the complexity but this is exactly what it can do, isn't it?
Instead of saying that all USB keyboards are allowed, if you know your vendor, then you say that exactly the keyboards you expect to be on your systems are allowed, etc...
I understand that no USB at the kernel level is safer but this is
pushing my
'usability vs security' balance warnings.
I.e. if, for whatever reason, I HAVE to use something USB on a system
that
can't have any downtime, you'd better believe that I'm going to leave
usb on
in the kernel. And, realistically, isn't that most of the systems you're trying to protect the most?
http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devi...
As for VMs, if I wanted to plug a USB device into a VM, I would need administrative access to the physical host to be able to attach the
virtual
device. If that's the case it doesn't really matter since I can pretty
much
do whatever I like to the VM (including copying its memory and disk) and
not
worry about it.
Yes, I know, whining and no patches....but I'm trying to have
constructive
whining ;-).
Thanks,
Trevor
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
On Thu, Apr 17, 2014 at 3:20 PM, Trey Henefield < trey.henefield@ultra-ats.com > wrote:
We have a mix a systems to which some require USB and some do not. While
it’s
not feasible to know the need of every system when applying this requirement, I have found some logic that seems to work:
USB_DEVICE=$(grep 'Product=' /proc/bus/usb/devices | egrep -ic '(ps2 to
usb
adapter|keyboard|kvm|sc reader)')
If [ $USB_DEVICE = 0 ]; then
DO SOME ACTION
fi
The above will check for a USB keyboard, a PS2 to USB adapter (needed
for a
USB keyboard in some cases), a USB KVM, and a CAC reader (only approved versions are USB).
It may be useful to add that logic to your fix.
Best regards,
Trey Henefield, CISSP
Senior IAVA Engineer
Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450
www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto: scap-security-guide-bounces@lists.fedorahosted.org ] On Behalf Of Trevor Vaughan Sent: Thursday, April 17, 2014 7:11 AM To: SCAP Security Guide Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line
argument
in /etc/grub.conf within bootloader_nousb_argument check
case-insensitively
Just out of curiosity, is adding nousb to the grub command line actually feasible for enforcement?
I can't remember the last time I used a system where I didn't need a USB keyboard at some point (can you even buy server class systems with PS/2 support any more?)
Trevor
On Wed, Apr 16, 2014 at 8:23 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh < Joshua.Kayse@gtri.gatech.edu> wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
- check for 'nousb' argument on kernel command line in /etc/grub.conf
within the bootloader_nousb_argument check in a case-insensitive way
- update comments where appropriate
- add test attestation timestamp
- replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by
programs
running once the system is up.
"nousb" was in the list as case sensitive.
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check
out.
Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that
list. I
vote we should follow what actually works and assume the kernel docs are
out
of date.
-josh
Also, according to
https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete...
that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
-josh
Thanks for that link!
Ack to Jan's patch.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.com sent at 2014-04-17 15:20:52 is private and
may
be legally privileged or export controlled. It is intended solely for
use by
scap-security-guide@lists.fedorahosted.org and others authorized to
receive
it. If you are not scap-security-guide@lists.fedorahosted.org you are
hereby
notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and
may
be unlawful.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
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
Hello folks,
1) apologize for my late reply (was on PTO in between).
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, April 17, 2014 2:23:31 AM Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh < Joshua.Kayse@gtri.gatech.edu > wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
- check for 'nousb' argument on kernel command line in /etc/grub.conf within the bootloader_nousb_argument check in a case-insensitive way
- update comments where appropriate
- add test attestation timestamp
- replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up.
"nousb" was in the list as case sensitive.
Checked the three (selinux, audit & nousb) options again, and now it looks they truly are case sensitive (only lowercase ones cause the desired effect).
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
On the system, I was checking the change there's been broken symbolic link /etc/grub.conf -> /boot/grub/grub.conf, so changing /etc/grub.conf command line didn't actually had effect on what got actually provided to the kernel's command / boot line (verified by cat /proc/cmdline on running system).
Editing /boot/grub/grub.conf directly (instead of /etc/grub.conf) with SELINUX=0, AUDIT=1, or NOUSB doesn't seem to cause anything different from the default behaviour.
Also checked with Petr Matousek (Red Hat's SRT representative for kernel) and he confirmed, the options should still be case sensitive, as visible in the code: http://lxr.linux.no/#linux+v3.14.1/kernel/params.c#L180
(there isn't section in parse_args() routine which would convert argument to it's lowercase prior checking for match).
Long story short, on the default RHEL-6 system, where /etc/grub.conf symlink to /boot/grub/grub.conf is not broken (and thus /etc/grub.conf change is actually projected when booting / re-booting) only lowercase version of the options is honoured.
So we should keep the current form of all three SCAP tests (checking audit, nousb & selinux options), and those three patches: https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/0052... https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/0052... https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/0052...
should NOT be applied, since they are wrong.
But this case (broken symlink from /etc/grub.conf to /boot/grub/grub.conf) made me to wonder if instead of checking /etc/grub.conf those tests shouldn't be checking /boot/grub/grub.conf configuration file directly (AFAICT both /etc/grub.conf and /boot/grub/menu.lst are just symbolic links to /boot/grub/grub.conf).
Sorry for the confusion (hopefully the above clears it).
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
-josh
Thanks for that link!
Ack to Jan's patch.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Apr 25, 2014, at 8:25 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
Hello folks,
- apologize for my late reply (was on PTO in between).
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, April 17, 2014 2:23:31 AM Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
On 4/16/14, 5:08 PM, Kayse, Josh wrote:
On Apr 16, 2014, at 8:06 PM, Kayse, Josh < Joshua.Kayse@gtri.gatech.edu > wrote:
On Apr 16, 2014, at 7:59 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
Patch summary:
- check for 'nousb' argument on kernel command line in /etc/grub.conf within the bootloader_nousb_argument check in a case-insensitive way
- update comments where appropriate
- add test attestation timestamp
- replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
I wasn't sure if nousb was case insensitive, so I checked https://www.kernel.org/doc/Documentation/kernel-parameters.txt
And found this:
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up.
"nousb" was in the list as case sensitive.
Checked the three (selinux, audit & nousb) options again, and now it looks they truly are case sensitive (only lowercase ones cause the desired effect).
Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out. Should we follow the kernel docs (which say case sensitive), or allow insensitivity since it actually works?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I’d like to point out that the selinux parameter is also within that list. I vote we should follow what actually works and assume the kernel docs are out of date.
-josh
Also, according to https://github.com/torvalds/linux/blame/master/Documentation/kernel-paramete... that line was last changed 2005. Perhaps someone should brave lkml and submit a patch.
On the system, I was checking the change there's been broken symbolic link /etc/grub.conf -> /boot/grub/grub.conf, so changing /etc/grub.conf command line didn't actually had effect on what got actually provided to the kernel's command / boot line (verified by cat /proc/cmdline on running system).
Editing /boot/grub/grub.conf directly (instead of /etc/grub.conf) with SELINUX=0, AUDIT=1, or NOUSB doesn't seem to cause anything different from the default behaviour.
Also checked with Petr Matousek (Red Hat's SRT representative for kernel) and he confirmed, the options should still be case sensitive, as visible in the code: http://lxr.linux.no/#linux+v3.14.1/kernel/params.c#L180
(there isn't section in parse_args() routine which would convert argument to it's lowercase prior checking for match).
I went looking to find where it was allowed to be insensitive and couldn’t find it so I’m glad I wasn’t missing something.
Long story short, on the default RHEL-6 system, where /etc/grub.conf symlink to /boot/grub/grub.conf is not broken (and thus /etc/grub.conf change is actually projected when booting / re-booting) only lowercase version of the options is honoured.
So we should keep the current form of all three SCAP tests (checking audit, nousb & selinux options), and those three patches: https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/0052... https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/0052... https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/0052...
should NOT be applied, since they are wrong.
But this case (broken symlink from /etc/grub.conf to /boot/grub/grub.conf) made me to wonder if instead of checking /etc/grub.conf those tests shouldn't be checking /boot/grub/grub.conf configuration file directly (AFAICT both /etc/grub.conf and /boot/grub/menu.lst are just symbolic links to /boot/grub/grub.conf).
I’ve seen this a lot due to bugs in augeas or perl modifications of /etc/grub.conf instead of /boot/grub/grub.conf and therefore I recommend that /boot/grub/grub.conf is checked instead of /etc/grub.conf
-josh
Sorry for the confusion (hopefully the above clears it).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
-josh
Thanks for that link!
Ack to Jan's patch.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Based on: [1] https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/0053...
please ignore / don't apply this patch, since it's wrong. See [1] for further explanation.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
----- Original Message -----
From: "Jan Lieskovsky" jlieskov@redhat.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, April 16, 2014 2:44:46 PM Subject: [PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively
Patch summary:
- check for 'nousb' argument on kernel command line in /etc/grub.conf within the bootloader_nousb_argument check in a case-insensitive way
- update comments where appropriate
- add test attestation timestamp
- replace path + filename ind construct with filepath one
Testing report:
- Tested on RHEL-6. Works fine.
Please review.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Jan Lieskovsky -
Kayse, Josh -
Roach, Brian -
Shawn Wells -
Trevor Vaughan -
Trey Henefield