[PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively

Trey Henefield trey.henefield at ultra-ats.com
Thu Apr 17 19:49:05 UTC 2014


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 at 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 at lists.fedorahosted.org [mailto:scap-security-guide-bounces at 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-devices#3.2_Locking_down_Linux_using_UDEV
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 at ultra-ats.com<mailto:trey.henefield at 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 at ultra-ats.com<mailto:Trey.Henefield at ultra-ats.com>
Tel: +1 512 327 6795 ext. 647<tel:%2B1%20512%20327%206795%20ext.%20647>
Fax: +1 512 327 8043<tel:%2B1%20512%20327%208043>
Mobile: +1 512 541 6450<tel:%2B1%20512%20541%206450>

www.ultra-ats.com<http://www.ultra-ats.com>

From: scap-security-guide-bounces at lists.fedorahosted.org<mailto:scap-security-guide-bounces at lists.fedorahosted.org> [mailto:scap-security-guide-bounces at lists.fedorahosted.org<mailto:scap-security-guide-bounces at 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 at redhat.com<mailto:shawn at 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 at gtri.gatech.edu<mailto:Joshua.Kayse at gtri.gatech.edu>> wrote:


On Apr 16, 2014, at 7:59 PM, Shawn Wells <shawn at redhat.com<mailto:shawn at 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 at lists.fedorahosted.org<mailto:scap-security-guide at 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-parameters.txt 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 at lists.fedorahosted.org<mailto:scap-security-guide at lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699<tel:%28410%29%20541-6699>
tvaughan at onyxpoint.com<mailto:tvaughan at onyxpoint.com>

-- This account not approved for unencrypted proprietary information --


Disclaimer
The information contained in this communication from trey.henefield at ultra-ats.com<mailto:trey.henefield at 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 at lists.fedorahosted.org<mailto:scap-security-guide at lists.fedorahosted.org> and others authorized to receive it. If you are not scap-security-guide at lists.fedorahosted.org<mailto:scap-security-guide at 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 at lists.fedorahosted.org<mailto:scap-security-guide at lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan at onyxpoint.com<mailto:tvaughan at onyxpoint.com>

-- This account not approved for unencrypted proprietary information --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140417/11939b54/attachment-0001.html>


More information about the scap-security-guide mailing list