8000 feature request: permit specifying a key in rules (enable safe deployments and logging/audit compliance) · Issue #665 · USBGuard/usbguard · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

feature request: permit specifying a key in rules (enable safe deployments and logging/audit compliance) #665

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.

Sign up for GitHub

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

Jump to bottom
Open
qralston opened this issue Apr 30, 2025 · 0 comments
8000
Open

feature request: permit specifying a key in rules (enable safe deployments and logging/audit compliance) #665

qralston opened this issue Apr 30, 2025 · 0 comments

Comments

@qralston
Copy link

Summary (TL;DR)

The fact that it is currently impossible to tell whether USBGuard took an action because a rule matched versus falling back to ImplicitPolicyTarget makes it impossible to safely deploy USBGuard in an enterprise environment in anything other than ImplicitPolicyTarget=allow mode, because it is not possible to verify that one’s rules correctly permit all devices that should be permitted.

Background

First: thanks to everyone working on USBGuard. This is a nice tool to have in the sysadmin toolbox, especially for sites that have to care about compliance issues.

Unfortunately, the current logging design of USBGuard is a significant impediment for deploying USBGuard in enterprise environments (hundreds or thousands of hosts, not a handful), where any USBGuard deployment must meet these criteria:

  1. The deployment must be automated, because it must occur at scale.
  2. The deployment must not break any required functionality on existing hosts.

To meet both requirements, a deployment plan for USBGuard in the enterprise would look something like this:

  1. Deploy USBGuard to all hosts, with no rules, and with ImplicitPolicyTarget=allow.
  2. Using centralized logging and audit logging, determine what rules are necessary in order to permit devices that should be permitted.
  3. Continue to refine step 2 over time until the ruleset permits all things that should be permitted.
  4. Finally, update the daemon configuration to ImplicitPolicyTarget=reject.

Performing steps 2 and 3 requires being able to determine whether USBGuard took an action because it found a matching rule, or because no rule matched and USBGuard took the action specified by ImplicitPolicyTarget.

Unfortunately, it is currently impossible to do this. Using usbguard-1.0.0-15.el9 on Red Hat Enterprise Linux 9, I tested the following configurations when connecting a USB keyboard with ImplicitPolicyTarget=allow:

  1. No rules defined.
  2. A single bare allow rule (permit everything) defined.
  3. A allow with-interface equals { 03:*:* } rule defined, followed by a bare allow rule.

In all three cases, USBGuard’s logging was identical; only the timestamps differed.

This, alas, is a showstopper for any type of enterprise deployment beyond ImplicitPolicyTarget=allow forever, because an enterprise cannot risk bricking hundreds or thousands of hosts. And unfortunately, ImplicitPolicyTarget=allow likely won’t be good enough for sites that have to care about compliance, because most compliance guidelines require a deny-by-default posture.

Solutions

Given that USBGuard already defaults to audit-style logging (or uses audit logging directly, in the case of AuditBackend=LinuxAudit), I think the cleanest solution here would be to update the USBGuard rule language to support a key. E.g.:

rule ::= target key device_id device_attributes conditions.

target ::= "allow" | "block" | "reject".

key ::= "key" text_string

device_id ::= "*:*" | vendor_id ":*" | vendor_id ":" product_id.

device_attributes ::= device_attributes | attribute.
device_attributes ::= .

conditions ::= conditions | condition.
conditions ::= .

The documentation for key:

Key

A rule may set an optional key. The argument to key is an arbitrary text string, up to 31 characters long.

If a rule declares a key, and the rule matches, the key will be included in the log message that USBGuard logs (either to the audit system or to USBGuard’s own audit file log). This aids in identifying which specific rule (out of potentially many, many rules) matched and thus caused USBGuard to take an action.

Keys do not affect rule matching. Keys only affect the information in the log message that USBGuard logs if the rule matches.

Keys do not need to be unique. For example, if multiple rules work together to enforce a specific security requirement, all rules can set the same key, in order to identify the specific set of rules that implemented the requirement.

If the case where no rule matches and USBGuard takes the action dictated by the ImplicitPolicyTarget option in usbguard-daemon.conf(5), the logged key value is ImplicitPolicyTarget.

The use of keys in rules is intended to mirror the use of keys in auditctl(8) rule fields, to provide similar rule sorting and identification capabilities.

By stealing borrowing the key concept from auditctl, it would become possible to safely deploy USBGuard at scale in an enterprise environment.

Moreover, for sites that are audited for compliance, keys in rules would greatly aid in demonstrating to an auditor that specific requirements are implemented via specific USBGuard rules.

Thoughts?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@qralston
0