Bug 1659575

Summary: [RFE] Enhancements for usbguard to improve usability for corporate desktop users
Product: Red Hat Enterprise Linux 7 Reporter: afox <afox>
Component: usbguardAssignee: Daniel Kopeček <dkopecek>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.6CC: dapospis, mthacker
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: 7.8   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1667395 (view as bug list) Environment:
Last Closed: 2019-02-20 14:28:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1667395    

Description afox@redhat.com 2018-12-14 17:14:53 UTC
1. Proposed title of this feature request
Enhancements for usbguard to improve usability for corporate desktop users

2. Who is the customer behind the request?
Account: 748231
TAM customer: Yes
SRM customer: Yes
Strategic: Yes

3. What is the nature and description of this request? 
On our RHEL6 desktops, we have a number of scripts that interact with udev that we use to restrict what USB storage devices people can plug into the system. Approved devices are held in a central white list and all other USB storage devices are blocked from being connected. However this has a number of downsides that we believe usbguard in RHEL7 solves (like blocking USB storage devices that present as keyboards).

Unfortunately there are a number of features that our own scripts provide to make our users lives easier that usbguard does not offer, as follows:

___________
1) Allow comments in /etc/usbguard/rules.conf file

Our own scripts ignore comments in the whitelist file. We sometimes include comments if there are odd devices where we need to provide extra information so we know what they are. In /etc/usbguard/rules.conf, we have the following:

---
allow id 8087:* with-interface 09:00:00
allow with-interface one-of { 03:00:01 03:01:01 }
allow with-interface one-of { 03:00:02 03:01:02 }
allow id 0b0e:0305 with-interface all-of { 01:01:00 01:02:00 01:02:00 01:02:00 01:02:00 03:00:00 }
---

From a sysadmin point of view we would like to annotate the file so that we can identify what these devices are.

We are currently working around this with a really bad hack:

---
allow with-interface one-of { 03:00:01 03:01:01 } name none-of { "all keyboards" }
allow with-interface one-of { 03:00:02 03:01:02 } name none-of { "all mice" }
allow id 26bd:9917 serial "07013859893D5521" with-interface 08:*:* name none-of { "SM000231 test device" }
allow id 0951:1665 serial "50E549C344361021795202D2" with-interface 08:*:* name none-of { "SM004321 anther test device - Western Digital 2TB HD" }
---

___________  ___________  ___________
2) Have a "/etc/usbguard/rules.d" folder

We have a central file that we update and our current scripts download this file and cache it locally when they detect a USB device has been plugged in. This allows us to update the central file and the changes are available to the user immediately.

With the current usbguard configuration we cannot do this. We either have to have all rules held centrally and then sync them to all the desktops, which introduces latency in the "request -> approve -> use" process (and introduces other scripts and processes) or don't do the sync and have the machine become unusable if it starts without a network connection. However we could work around this if usbguard adhered to the "conf.d" standard of having individual files in a directory and then read its rules from every file.

For example, this functionality would allow:

a) The generic configuration (mice, keyboards, host controllers) required for every workstation to be in "/etc/usbguard/rules.d/general.conf"
b) A list of USB headsets to be listed in "/etc/usbguard/rules.d/headsets.conf"
c) A list of USB storage devices to allowed to be in "/etc/usbguard/rules.d/usbstorage.conf"
d) A list of blocked or rejected devices in "/etc/usbguard/rules.d/reject-or-block.conf"

We could then symlink items (b) and (c) to nfs locations thus maintaining the instant approval and use of devices while also allowing USB host controllers, keyboards and mice if the machine starts up without a network connection (which sometimes happens).

___________  ___________  ___________
3) End user notifications

Users of desktops want to know if the device they have plugged in is allowed for use or not. Currently the only way for a user to tell if is is allowed is to see if it is mounted which really is not very helpful. This is another retrograde step from our own scripts and something that would make it much easier for standard users if usbguard could do.

Just to be clear about this, standard users only need to be told that a device was:

a) Allowed - with a suitable message
b) Blocked - with a suitable message

And it would be really good if we could customise the actual message that the user sees. The messages we uses are such that the system for end users is self explanatory and needs no end-user documentation. If the USB storage device is approved it says so. If it is blocked, it tells them it is blocked and tells them what to do to get it approved.

It would probably be OK to not show messages that were connected when usbguard started.

They do not need to be able to self approves devices or look at the current rules.

4. Why does the customer need this? (List the business requirements here)
They have a very large estate consisting of over 600 RHEL desktop users, and want to use standard RHEL features rather than script their own. This makes life easier going forward during upgrades etc. 

5. How would the customer like to achieve this? (List the functional requirements here)
Requirements are listed above. 

6. Is there already an existing RFE upstream or in Red Hat Bugzilla?
Not that I can find.

7. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL6, RHEL7)?
RHEL 7.7 and RHEL 8 GA

8. Is the sales team involved in this request and do they have any additional input?
No. 

10. List any affected packages or components.
usbguard

11. Would the customer be able to assist in testing this functionality if implemented?
Yes

Comment 3 Daniel Kopeček 2019-01-18 11:03:31 UTC
Re-targeting to 7.8 as that seems to be a realistic timeframe to deliver the proposed feature.

Implementing comment in the rule file is a planned feature in upstream.
The rules.d folder would be also a nice feature but requires some internal refactoring in usbguard-daemon.

Comment 6 Daniel Kopeček 2019-02-20 14:28:23 UTC
We won't deliver the requested enhancements in RHEL-7. There is a RHEL-8 specific ticket and we are going to reconsider to deliver the enhancements in RHEL-8 provided they will be implemented in upstream first.