search

USBGuard / usbguard

USBGuard is a software framework for implementing USB device authorization policies (what kind of USB devices are authorized) as well as method of use policies (how a USB device may interact with the system)
https://usbguard.github.io/
GNU General Public License v2.0
1.12k stars 138 forks source link

Network adapter not starting when allowed #610

Closed michel404 closed 6 months ago

michel404 commented 9 months ago

I have a laptop with an external USB Ethernet network adapter. Without running usbguard I can unplug and re-plug in the device to my hearts content, without problems. But with usbguard, the adapter only works at startup, and after plugging it back in the network interface doesn't work.

I added a rule to allow this device, so it is not a matter of rules or allowing or disallowing.

My setup/how to reproduce the problem:

The problem occurs either when I first unplug the device and then plug it back in, or when I first block the device and then allow it again. So even though the device is allowed, I cannot use it.

To reproduce the problem I run: (assume the device has device id 37)

$ usbguard block-device 37
$ usbguard allow-device 37

I run Fedora Linux 39.20231225.0 (Silverblue) on a 12th Gen Intel Core Framework Laptop, and some white label usb-hub-ethernet-all-in-one-adapter via yet another usb hub integrated in my (usb type C) monitor.

Expected/correct situation:

When the device does work (after boot with the network adapter plugged in, or when the adapter is plugged in for the first time) I get this for usbguard list-devices:

[...]
37: allow id 0bda:8153 serial "001000001" name "USB 10/100/1000 LAN" hash "ebdNZoLaX1yvphZGBxIS7c6OFgxhIVrXy8hs3DEM5w0=" parent-hash "+B8+v40hqFWD2AApR0L4mLCJJX6rihTvdbvVV3Gc/j0=" via-port "3-5.4.4" with-interface { ff:ff:00 02:06:00 0a:00:00 0a:00:00 } with-connect-type "unknown"

and this for ip link: (note: the id numbers may be different)

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s20f0u5u4u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether [MAC] brd ff:ff:ff:ff:ff:ff
3: wlp166s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether [MAC] brd ff:ff:ff:ff:ff:ff

and this for lsusb:

$ lsusb --tree -v
[...]
            |__ Port 004: Dev 012, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
                ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
[...]

Actual/problematic situation:

When the device doesn't work (after blocking and allowing, or after unplugging and re-plugging in) I get this for usbguard list-devices: (note: no difference)

[...]
37: allow id 0bda:8153 serial "001000001" name "USB 10/100/1000 LAN" hash "ebdNZoLaX1yvphZGBxIS7c6OFgxhIVrXy8hs3DEM5w0=" parent-hash "+B8+v40hqFWD2AApR0L4mLCJJX6rihTvdbvVV3Gc/j0=" via-port "3-5.4.4" with-interface { ff:ff:00 02:06:00 0a:00:00 0a:00:00 } with-connect-type "unknown"

and this for ip link: (note: no ethernet interface)

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: wlp166s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether [MAC] brd ff:ff:ff:ff:ff:ff

and this for lsusb: (note: 2 records and no drivers)

$ lsusb --tree -v
[...]
            |__ Port 004: Dev 012, If 0, Class=Communications, Driver=[none], 480M
                ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
            |__ Port 004: Dev 012, If 1, Class=CDC Data, Driver=[none], 480M
                ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
[...]
I think these `[none]`s suggest that the driver isn't loaded or something.

Workaround

If I remove the driver module from my Linux kernel before I reconnect the adapter, it reloads on reconnect and the device does work. So my workaround is this:

$ usbguard block-device 37 # or unplug the adapter
$ sudo rmmod r8153_ecm
$ sudo rmmod r8152
$ usbguard allow-device 37 # or plug the adapter back in

I don't know nearly enough to about the usb protocol and the Linux kernel to know what and why this happens, but hopefully this can be fixed. I love having usbguard installed on my system, and this is quite an inconvenience :-)

michel404 commented 9 months ago

Oh, and happy holidays to anyone reading this around Xmas time :christmas_tree: :star2:

muelli commented 9 months ago

Could this be GNOME blocking the device? Is your screen unlocked when you plug the device in?

michel404 commented 9 months ago

Good question. I don't think GNOME is blocking the device. My screen is unlocked when I plug the device back in. Also when I run the usbguard allow-device 37 command, my screen is unlocked.

Is there a way for me to check whether GNOME is blocking anything?

traidare commented 9 months ago

I think I have the same problem.

My network adapter only works when booting while plugged in. If I disable the usbguard service and reboot, I can plug it in and out and it keeps working.

As with @michel404, when plugging in (and usbguard working) there is no ethernet interface.

EDIT: This is a different problem (I probably caused trying to solve this issue) I will solve tomorrow after some sleep: EDIT2: This was a hardware problem by the way - the cable just wouldn't stick with the adapter. (After I repeatedly pulled it out and plugged it in - maybe a bit too rough.)

Unfortunately michels workaround is not quite working for me. After unplugging, removing drivers, and plugging in, there is at least an interface, although it is not working. When this is the case, I get the following output:

~> ip link show eth0
8: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:e0:4c:68:03:a1 brd ff:ff:ff:ff:ff:ff
~> lsusb --tree -v
[...]
    |__ Port 001: Dev 026, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
        ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
[...]

I run Void Linux with Sway (so no problem with GNOME), also on a 12th Gen Intel Core Laptop (Starlabs StarBook i7-1260P).

I don't remember this being a problem a few weeks/months ago (although I could of course be wrong about this). The only recent change regarding usbguard in the Void Linux repository was an update of libsodium.

TimEberhardt commented 6 months ago

Same problem here on Gentoo Linux with usbguard 1.1.2 on kernel 6.6.16. I have a Latitude 5491 with Dell USB-C docks. In both of my offices it is the same problem. When booting with dock plugged in, everything is working. When plugging in the dock later or after suspend keyboard/mouse/display is working over the dock but network isn't. I have this problem a couple of weeks now. Internal NIC is always working.

michel404 commented 6 months ago

I don't know what happened, but it appears as if this issue is resolved for me now. The only thing I think has changed is that I kept my software (i.e. my OS) up-to-date. For the record, now I'm running Fedora Linux 39.20240324.0 (Silverblue) and still the same usbguard-1.1.2-1.fc39.x86_64.