The Linux USB Policy V2 lets administrators allow or block USB devices and individual USB functions on managed Linux devices.

Instead of applying one setting to every USB connection, the policy uses rules. Each rule can match:

The rule then authorizes or deauthorizes the matching device or interface.

Common use cases include:

The policy is available for both company-owned and BYOD Linux devices.

Important: Test USB restrictions on a nonproduction device before broad deployment. A rule that blocks HID devices, hubs, wireless controllers, or a whole composite device can disable keyboards, mice, docks, network adapters, Bluetooth hardware, or other required peripherals.

The effective behavior depends on the Linux kernel, USB device descriptors, drivers, hardware topology, and distribution configuration.

Linux exposes an authorization state for USB devices and USB interfaces. A device or interface with an authorized value of 1 is allowed to operate. Setting the value to 0 deauthorizes it.

Linux supports control at two levels:

Linux kernel documentation explains both authorization levels in Authorizing USB devices to connect to the system.

Swif creates Linux USB authorization rules from the settings in this policy. When a configured USB event occurs and the device or interface matches the rule, Swif applies the selected authorization state.

The policy controls the operating system's use of USB devices. It does not:

Selecting the correct rule level is essential.

A rule with Rule Level set to usb_device evaluates the class in the device descriptor and changes authorization for the entire USB device.

Use this level when:

Blocking a whole composite device can disable every function it provides. For example, blocking a USB dock at the device level can affect storage, Ethernet, audio, video, and connected peripherals.

A rule with Rule Level set to usb_interface evaluates the class in an interface descriptor and changes authorization for that individual function.

Use this level when:

For broad USB mass-storage control, use usb_interface with class 08 Mass Storage. Many flash drives and composite devices expose storage as an interface rather than as the whole device's class.

Note: Some drivers require several interfaces to operate together. Blocking one interface can cause the whole peripheral or one of its other functions to behave unexpectedly. Reauthorizing an interface may also require a reconnect or driver reprobe. Test representative hardware before production deployment.

Before creating the policy:

Do not begin testing by broadly blocking HID devices, hubs, or wireless controllers.

Connect the device and run:

Example output:

In this example:

Enter vendor and product IDs as exactly four hexadecimal characters without 0x.

To inspect the USB topology and interface classes:

For more detailed descriptor information:

Detailed USB output may contain serial numbers and other hardware identifiers. Redact sensitive values before sharing logs or screenshots.

For a company-owned workstation that must block removable USB storage:

This rule targets mass-storage interfaces without intentionally blocking unrelated HID, audio, video, or network interfaces.

Test phones, cameras, docks, card readers, encrypted drives, and multifunction devices separately. A device can expose more than one class, and its behavior may differ between operating modes.

USB Rules is a list of individual authorization rules. Each rule contains its own event, scope, class, authorization, and optional hardware identifiers.

Keep the rule set as small and specific as possible. Avoid overlapping allow and block rules for the same hardware unless you have tested the effective result. Conflicting rules can make behavior dependent on which device or interface event is processed.

Trigger Actions specifies the Linux USB events that cause a rule to be evaluated.

For general USB control, select add, bind, and change so the rule can respond across normal discovery and driver activity.

If a device was already connected before the policy was applied, disconnect and reconnect it during a controlled test to ensure that a new event occurs.

Rule Level determines which USB descriptor and authorization target the rule uses.

Use usb_interface for classes normally declared on interfaces, including HID, mass storage, printer, audio, and video. Use usb_device when you intentionally need to control the entire hardware device.

USB Class Code identifies the type of USB device or function to match.

USB class information can appear in a device descriptor, an interface descriptor, or both, depending on the class. The USB Implementers Forum maintains the authoritative USB defined class codes.

Class 00 does not mean that a device has no function. At the device level, it commonly means that the actual functions must be read from the interface descriptors.

Authorization determines what happens to a matching device or interface.

Use Blocked to prevent Linux from using the matched target.

Use Allowed only as part of a tested rule design, such as reauthorizing an approved target. Linux authorizes USB devices and interfaces by default unless another rule or system configuration changes that behavior. An allow rule by itself is not a complete default-deny USB allowlist.

Vendor ID optionally limits the rule to a USB vendor.

The value must contain four hexadecimal characters.

Example:

Leave the field empty when the rule should match the selected class across all vendors.

Vendor IDs are device-provided identifiers. They help narrow a rule but should not be treated as cryptographic proof that a peripheral is trusted.

Product ID optionally limits the rule to a USB product.

The value must contain four hexadecimal characters.

Example:

For a model-specific rule, configure both Vendor ID and Product ID. Leave this field empty when the product does not need to be narrowed.

A product ID can be reused across device revisions, and a programmable device can imitate descriptor values. Treat vendor and product IDs as matching attributes rather than strong device identity.

This is the recommended starting point when the goal is to prevent USB storage while retaining other USB classes.

Replace the example IDs with the values reported by lsusb.

Test conferencing devices before deployment. A single physical device may expose video, audio, and HID interfaces separately.

Use this configuration only when every function of the matched device should be unavailable.

Use extra caution with these classes:

Internal webcams, fingerprint readers, Bluetooth adapters, cellular modems, and other built-in components may connect internally through USB. A restriction can affect them even when the user did not plug anything into an external port.

For company-owned Linux devices:

For personally owned devices:

This policy affects the Linux operating system, not only a work container or work profile.

After applying the policy:

List connected devices:

Show USB topology and interface drivers:

Review recent kernel messages:

Depending on distribution logging and permissions, USB event details may also be available through:

Start monitoring before reconnecting the test device. Stop it with Ctrl+C.

Do not publish unredacted logs that contain device serial numbers or other sensitive identifiers.

Some phones and cameras use media-transfer, image, vendor-specific, or networking interfaces rather than USB mass storage.

This can be expected. USB deauthorization prevents the operating system from using the matched device or interface; it does not necessarily hide all descriptor or connection information from hardware inventory.

Verify whether the corresponding storage, video, network, printer, or other function is actually usable.

This is expected when an interface-level rule matches only one function.

Do not assume that an allow rule automatically overrides every block rule. Avoid conflicting matches unless their effective behavior has been validated.

Do not deploy the same rule to additional devices until the cause is understood.

Linux kernel behavior may require the driver to probe the interface again after reauthorization.

Try:

Do not manually change sysfs authorization values on production devices unless you understand the affected hardware and have a recovery path.

The configured trigger actions correspond to USB events. A device that was already present may not generate a matching new event until it is reconnected, rebound, changed, or the system restarts.

Verify the policy with a controlled disconnect and reconnect. If behavior remains inconsistent, collect the policy result, distribution and kernel version, lsusb output, lsusb -t output, and relevant kernel logs for Swif Support.

Example:

Do not assume a policy bug when the USB device is not visible to the guest operating system. Verify USB passthrough first.

When troubleshooting an unexpected policy result, collect the following before contacting Swif Support:

This file shows the rules Swif applied. If the file does not exist, the policy may not have been installed or may have already been removed.

Include the policy JSON from the Swif Admin Dashboard, the Linux distribution and kernel version, and any relevant agent or kernel logs alongside the diagnostic output above.

USB authorization rules can reduce exposure to removable-media data transfer, unapproved peripherals, and some classes of malicious USB devices. They are one layer of endpoint control.

For a secure deployment:

USB class, vendor ID, and product ID are not strong device authentication. Linux kernel documentation warns that device descriptors can be imitated. Do not rely on this policy alone when cryptographic peripheral identity or complete data-loss prevention is required.

This policy can support device-control and data-protection objectives, but it does not independently make an organization compliant with a particular framework.

Linux USB Policy V2 controls USB access with rules based on event, scope, class, and optional hardware identifiers.

For most organizations that need to block removable USB storage: