Bug 1479241 - [RFE] Make it possible to whitelist only encrypted USB flash drives
[RFE] Make it possible to whitelist only encrypted USB flash drives
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: usbguard (Show other bugs)
7.4
Unspecified Unspecified
medium Severity unspecified
: pre-dev-freeze
: 7.5
Assigned To: Daniel Kopeček
BaseOS QE Security Team
: FutureFeature, Triaged
Depends On:
Blocks: 1490339
  Show dependency treegraph
 
Reported: 2017-08-08 03:35 EDT by Daniel Kopeček
Modified: 2017-10-13 07:49 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1490339 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Github dkopecek/usbguard/issues/198 None None None 2017-08-08 03:36 EDT

  None (edit)
Description Daniel Kopeček 2017-08-08 03:35:35 EDT
Description of problem:

(From the upstream ticket)

Flash drives are widely used to share information between computers. In high security environments the use of the USB flash drives is not allowed because the data can be stolen. Network bound disk encryption allows data to be bound to network. So if a device can be encrypted and used only on the network then the data can't be stolen since it is encrypted. There is currently no integration with network bound disk encryption. The requested feature is to enhance USB guard to have a policy to allow only NBDE encrypted drives to enforce that only encrypted USB devices can be used in the high security environments and data is not leaked or stolen.
Comment 1 Jiri Jaburek 2017-08-08 06:25:24 EDT
NBDE (well, clevis) is really just a way to get password for a LUKS keyslot over network, there's not much to "integrate" with. Maybe a generic usbguard rule match for drives with LUKS metadata, so anything non-LUKS would be blocked/rejected, but then you run into issues of partitions and the entire solutions becomes pretty "hacky".

Plus it can be easily faked via a fake LUKS header ie. in the first few-KB-wide partition, with the unencrypted data in the second one. Or with a partition scheme usbguard wouldn't anticipate (ie. GPT, Apple Partition Map, etc., all of which are recognized by the kernel).
Even if we were to allow only no-partition-LUKS, it could still be faked via a number of other ways.

What would make more sense to me instead is to provide another layer of security by using (generic) signatures at the beginning of the USB drive, possibly authenticated using tang (the "server" in the NBDE scheme), independently of whether the drive (or any partitions on it) is encrypted or not.
Comment 2 Nathaniel McCallum 2017-08-08 12:38:00 EDT
I don't think the signature option can work. The signature would have to sign data reported by the USB device itself (such as manufacturer, product, serial, etc). However, this data can be easily spoofed by readily available and inexpensive programmable hardware. This would mean that an attacker could easily copy the signature from one device to another in order to foil the device level authentication.

Since we are depending on specially crafted partition/LUKS/clevis layouts anyway, we can just define a very narrow format we support and reject all others.
Comment 3 Nathaniel McCallum 2017-08-08 12:48:49 EDT
Let's make a threat model. We assume that the goal of the attacker is to exfiltrate data on a trusted system using a USB key.

1. The user creates a normal filesystem with or without a partition table. USBGuard should reject this and allow only LUKS.

2. The user creates a LUKS device without a partition table. However, the user knows the LUKS password. USBGuard could check to see if there is clevis metadata with luksmeta.

However, since clevis itself listens to password prompts, the attacker could simply fake clevis metadata and then answer the prompt themselves with the known password. In order to bypass this, we need a way to disable these prompts.

This means that clevis needs to take over LUKS unlocking. A much less invasive change would be for clevis to define its own on-disk format and handle its own unlocking. In this case, clevis could define that the disk is non-interactive and would never prompt the user at all. USBGuard could then allow only these non-interactive volumes.

Note You need to log in before you can comment on or make changes to this bug.