-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for usbguard package inclusion #326
Comments
See also https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs_usb.md - I think we're basically still at the point where simply plugging in a device can gain arbitrary code execution in the kernel. Yes...it's that bad and one should use USB condoms too. One high level sugar I think we could add here might be "automatically allow all USB devices detected at provisioning (Ignition time)". |
Minor annoyance: on F31 we would get a spurious |
Additional annoyance: the daemon is configured via single files in OS vendor defaults/logic and user customizations may clash over rules-file ownership. There is USBGuard/usbguard#224 open to improve the situation on upstream side. |
Taking a step back, the underlying blocking logic is performed kernel-side as shown in https://www.kernel.org/doc/Documentation/usb/authorization.txt. The basic case of "do not trust newly attached USB device" can be fully handled by |
@JAORMX Is there a specific need for USBGuard, it's domain-specific rules language, or just the mechanism for control around USB devices. While obtuse to some users, much of the functionality of USBGuard can be achieved with udev rules. The functionality which seems to be outside of the domain of udev (namely access control for non-administrative users) gets into concerns more focused on the desktop use case. If we were to write a blog post or documentation on how to do this with used with udev this has the potential to benefit all distros using udev and not just FCOS. Would this be sufficient? If so, I'll commit to writing something up (or collaborating with you to write something up) for Fedora Magazine as an initial triage before the end of the calendar year. |
dropping the meeting label since we discussed in the last meeting. @JAORMX - do you care to answer the questions posed above ^^ ? |
@dustymabe I was gonna answer but then went on vacations (still on vacations), le tme get someone to answer this. Thanks for the reminder! |
@brianredbeard our target user uses the OpenSCAP features we're adding to OCP to automate satisfying this NIST guideline and others on their nodes, and our SCAP policy content (https://github.com/ComplianceAsCode) already contains checks and remediations via USBGuard. Being able to use the existing content on CoreOS will really speed up adoption so that is one of our aims. Also, USBGuard has been identified as satisfying controls for Common Criteria as well. |
usbguard is available to install as an overlayed rpm using a unit similar to https://github.com/keithy/ign-tool/wiki/plug:rpm-ostree-install-overlays |
Before we merge content into the host by default, the basic question has to be asked: Why can/should this not be a container? In this case we have non-containerized code that is known to work, which I understand, but we've invested in containerizing other components too. Another aspect of this is that usbguard is a little silly to run in cloud environments. (We could consider perhaps just turning off USB entirely in e.g. AWS/GCP/OpenStack by default) |
One other comment; we did recently blaze the trail of (for RHCOS) including non-default RPMs in To be honest I'm fine probably adding it to CoreOS systems by default; not really happy with that, but I'm personally unlikely to try containerizing it myself. |
@JAORMX - it would still be good to get some answers to the questions in #326 (comment). From the response by @mrogers950 it sounds more like the story is:
rather than
IOW if there was a way to achieve the goal without using USBGUARD, would it still be satisfactory? |
Sounds like a job for an ignition plug(in)/snippet for that use case. |
And for FCOS, nothing stops us from e.g. creating a filtered subset of RPMs from the whole Fedora repos that we may at least be more likely to test. (For example, there's a wild difference between package layering |
@dustymabe , @brianredbeard : it doesn't satisfy the same requirements. Here's the text from a response @stevegrubb gave me:
|
See also ComplianceAsCode/content#4748 . For a system that never runs on physical hardware and never needs USB (which might be the case here), the easiest option is to just If the system never needs plug-in USB devices (ie. a keyboard for emergencies), then allowing everything present during boot and denying everything else is the next easiest option. This can be done via USBGuard's
see the comments in If needed, this shouldn't be impossible to do without USBGuard - ie. using a systemd service or an udev rule that sets Finally, if you need to allow some devices to be plugged-in during runtime, the situation gets notably more complex as ie. not all HID devices are created equal - see the ComplianceAsCode issue referenced above. |
we discussed this in the meeting today:
The RFE for the "reliable extensions" framework mentioned above is opened as #401 |
It seems usbguard is supported in OpenShift from 4.6. Perhaps another look at usbguard for FCOS would be a good thing? |
From my PoV, https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable subsumes this use case for FCOS, and https://github.com/openshift/enhancements/blob/master/enhancements/ocp-coreos-layering/ocp-coreos-layering.md generalizes it for OCP. |
Scenario
a malicious actor walks into the data center a plugs a USB in a node running CoreOS.
Proposal
The deployer should be able to specify a policy for what devices are allowed. This would be covered by adding the usbguard package to CoreOS, and subsequently allowing the deployer to configure that (it's possible via MachineConfig).
Referenced NIST control(s)
SC-7(14)
The text was updated successfully, but these errors were encountered: