Request for usbguard package inclusion

[JAORMX]

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)

[cgwalters]

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)".

[lucab]

Minor annoyance: on F31 we would get a spurious emacs-filesystem in the image due to transitive dependency from this. I filed https://bugzilla.redhat.com/show_bug.cgi?id=1783240 to hopefully get rid of that.

[lucab]

Additional annoyance: the daemon is configured via single files in /etc/usbguard (usbguard-daemon.conf and rules.conf).

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.

[lucab]

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 authorized_default in sysfs, without introducing additional packages.

[brianredbeard]

@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.

[dustymabe]

dropping the meeting label since we discussed in the last meeting. @JAORMX - do you care to answer the questions posed above ^^ ?

[JAORMX]

@dustymabe I was gonna answer but then went on vacations (still on vacations), le tme get someone to answer this. Thanks for the reminder!

[mrogers950]

@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.

[keithy]

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

[cgwalters]

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)

[cgwalters]

One other comment; we did recently blaze the trail of (for RHCOS) including non-default RPMs in machine-os-content for kernel-rt, so another option is to continue that and stick usbguard as an option that can be e.g. turned on via machineconfig or so. For FCOS of course as already noted package layering it should work fine.

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.

[dustymabe]

@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:

• we need USBGUARD because usbguard is a blessed tool to achieve the goal of blocking USB devices

rather than

• we need to be able to configure blocking USB devices

IOW if there was a way to achieve the goal without using USBGUARD, would it still be satisfactory?

[keithy]

Sounds like a job for an ignition plug(in)/snippet for that use case.

[cgwalters]

we did recently blaze the trail of (for RHCOS) including non-default RPMs in machine-os-content for kernel-rt

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 usbguard and package layering gnome-shell on CoreOS systems...)

[JAORMX]

@dustymabe , @brianredbeard : it doesn't satisfy the same requirements. Here's the text from a response @stevegrubb gave me:

Yes. This is to prevent bypass of information flow if they jam in a usb wifi
stick which may cause routing and dns changes. Also, the policy is to allow
keyboards, mice, and hubs only for system recovery. They are proposing to
allow anything connected at boot. That is not the same policy.
Generally, you want an audit event to be generated whenever an access control
decision is made. Usbguard already has this baked in.
Also, you get into a strange world in security when the enforcement is a
script. This is the whole problem with policykit being javascript. What you
really want for security is name = value so that you can just check that
something is installed and that its got the right settings. If its a script,
you can have white space changes, overrides, inclusions and all sorts of
shenanigans to where you don't know what the script is really doing.
To be honest, I don't know if you can do the equivalent in udev. I have a
feeling that checking it will be impossible. Being able to test that
something is configured right is one of the most important aspects of
security.

[comps]

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 usbcore.nousb or nousb (on older kernels) on the kernel command line.

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

ImplicitPolicyTarget
PresentDevicePolicy
PresentControllerPolicy
InsertedDevicePolicy

see the comments in /etc/usbguard/usbguard-daemon.conf. Also note that - in this case - there should be some alert when a system gets rebooted, as without such alert, silently authorizing a malicious device is fairly easy.

If needed, this shouldn't be impossible to do without USBGuard - ie. using a systemd service or an udev rule that sets authorized_default on all controllers to 0 during boot. Any new plugged-in devices will then inherit the 0 and remain deauthorized. Some people would however consider this a hack given that there's an officially supported and tested software that can do that.

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.

[dustymabe]

we discussed this in the meeting today:

12:12:31  dustymabe | #agreed usbguard fits into a category of small OS utility/daemon that is not easy
                    | or desirable to containerize but is also not something we immediately want to
                    | include in the host because if we include every utility/daemon we end up with a
                    | kitchen sink OS. We'd like to develop a framework for "reliable extensions" that we
                    | can use to deliver usbguard and other utilities/daemons

The RFE for the "reliable extensions" framework mentioned above is opened as #401

[dustymabe]

Note that the above is talking about FCOS. While we do generally put packages in FCOS first, RHCOS may make a different decision for a tactical short term while we work out #401. Also package layering is an option but can cause updates to be less reliable (see #400).

[smuda]

It seems usbguard is supported in OpenShift from 4.6. Perhaps another look at usbguard for FCOS would be a good thing?

[cgwalters]

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.