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 < [email protected]> 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 > > > > [email protected] > > Tel: +1 512 327 6795 ext. 647 > > Fax: +1 512 327 8043 > > Mobile: +1 512 541 6450 > > > > www.ultra-ats.com > > > > *From:* [email protected] [mailto: > [email protected]] *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 < > [email protected]> 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 > > > > [email protected] > > Tel: +1 512 327 6795 ext. 647 > > Fax: +1 512 327 8043 > > Mobile: +1 512 541 6450 > > > > www.ultra-ats.com > > > > *From:* [email protected] [mailto: > [email protected]] *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 <[email protected]> wrote: > > On 4/16/14, 5:08 PM, Kayse, Josh wrote: > > > > On Apr 16, 2014, at 8:06 PM, Kayse, Josh <[email protected]> > wrote: > > > > > > On Apr 16, 2014, at 7:59 PM, Shawn Wells <[email protected]> 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 > [email protected] > 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > [email protected] > > -- This account not approved for unencrypted proprietary information -- > > > > *Disclaimer* > The information contained in this communication from > *[email protected] > <[email protected]> *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 *[email protected] > <[email protected]> *and others authorized to > receive it. If you are not *[email protected] > <[email protected]> *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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > [email protected] > > -- This account not approved for unencrypted proprietary information -- > > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information --
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
