4 ms·

what are you talking about? I have to approve the website before it can access my devices via WebUSB. What's the actual issue / path for keylogging etc. there,

what are you talking about? I have to approve the website before it can access my devices via WebUSB. What's the actual issue / path for keylogging etc. there, care to explain instead of fearmongering?

tuananh 2y ago
i'm just guessing here but maybe only chrome is asking that. if the malware is another program, no confirmation is required?
tuananh 2y ago
taking this from vial website ``` export USER_GID=`id -g`; sudo --preserve-env=USER_GID sh -c 'echo "KERNEL==\"hidraw\", SUBSYSTEM==\"hidraw\", ATTRS{serial}==\"vial:f64c2b3c*\", MODE=\"0660\", GROUP=\"$USER_GID\", TAG+=\"uaccess\", TAG+=\"udev-acl\"" > /etc/udev/rules.d/99-vial.rules && udevadm control --reload && udevadm trigger' ``` so that means the device can be read and written by the user and group, but not by others.
- tetris11 2y ago
  Yeah I have this udev rule, it fails to trigger properly and I think it might be because of what it thinks the user group and the web browser group is. I haven't fully debugged it, but I can tell you that this does not work for me
  - terinjokes 2y ago
    If you're on reasonably updated distribution, setting the GROUP in the udev rule might be causing issues. The [uaccess way][0] is to just set the TAG. SUBSYSTEMS=="usb", ATTRS{idVendor}=="vendor_id", ATTRS{idProduct}=="product_id", MODE="0660", TAG+="uaccess" The Arch Wiki also has this note: > For any rule adding the uaccess tag to be effective, the name of the file it is defined in has to lexically precede /usr/lib/udev/rules.d/73-seat-late.rules. If your application is running as a different user, or in a Flatpak or snap, you may need some additional or alternative configuration. [0]: https://wiki.archlinux.org/title/Udev#Allowing_regular_users_to_use_devices https://wiki.archlinux.org/title/Udev#Allowing_regular_users...
    - tetris11 2y ago
      Oh thanks for this
deleted 2y ago
[deleted]
vbezhenar 2y ago
Windows and macOS allow access to USB devices for user programs. Linux by default does not allow access to USB devices, you need to chmod corresponding pseudo-file in /dev (or write udev rule to make it happen automatically). So when one uses WebUSB (or any other usb software) without root, it won't work immediately.
- junon 2y ago
  Missing the point entirely. You must still enable USB support from the site before it can see or interact with anything.
  - vbezhenar 2y ago
    It has nothing to do with sites. You are missing the point. To access USB device with Linux, any software, including browser, should have permission to access certain files in /dev.
    - junon 2y ago
      You visit a page. It asks for device access. You get a dialog box choosing the device that matches the filter the site wants. You can either choose a device or decline. Site does not see anything other than what you approve. What is difficult about understanding that?
      - deleted 2y ago
        [deleted]
      - deleted 2y ago
        [deleted]
      - kuschku 2y ago
        You're the one missing the forest for the trees. The security risk is not caused by websites, but by the fact that the browser can access your USB devices in the first place. By giving the browser access to your USB devices, the browser could act as a keylogger even when you're using other applications. Further, as there's no proper way to sandbox this, you wouldn't just be giving the browser keylogging capabilities, but any native app running under your user.
kuschku 2y ago
The browser itself shouldn't have access to raw devices, as that means giving all programs running under your user the ability to flash your keyboard firmware. The point of flatpak, wayland, etc is to prevent software from having access to everything. Making all USB devices readable and writable again circumvents the entire sandboxing concept of modern systems.

tuananh 2y ago

i'm just guessing here but maybe only chrome is asking that. if the malware is another program, no confirmation is required?

tuananh 2y ago

taking this from vial website ``` export USER_GID=`id -g`; sudo --preserve-env=USER_GID sh -c 'echo "KERNEL==\"hidraw\", SUBSYSTEM==\"hidraw\", ATTRS{serial}==\"vial:f64c2b3c*\", MODE=\"0660\", GROUP=\"$USER_GID\", TAG+=\"uaccess\", TAG+=\"udev-acl\"" > /etc/udev/rules.d/99-vial.rules && udevadm control --reload && udevadm trigger' ``` so that means the device can be read and written by the user and group, but not by others.

tetris11 2y ago
Yeah I have this udev rule, it fails to trigger properly and I think it might be because of what it thinks the user group and the web browser group is. I haven't fully debugged it, but I can tell you that this does not work for me
- terinjokes 2y ago
  If you're on reasonably updated distribution, setting the GROUP in the udev rule might be causing issues. The [uaccess way][0] is to just set the TAG. SUBSYSTEMS=="usb", ATTRS{idVendor}=="vendor_id", ATTRS{idProduct}=="product_id", MODE="0660", TAG+="uaccess" The Arch Wiki also has this note: > For any rule adding the uaccess tag to be effective, the name of the file it is defined in has to lexically precede /usr/lib/udev/rules.d/73-seat-late.rules. If your application is running as a different user, or in a Flatpak or snap, you may need some additional or alternative configuration. [0]: https://wiki.archlinux.org/title/Udev#Allowing_regular_users_to_use_devices https://wiki.archlinux.org/title/Udev#Allowing_regular_users...
  - tetris11 2y ago
    Oh thanks for this

deleted 2y ago

[deleted]

vbezhenar 2y ago

Windows and macOS allow access to USB devices for user programs. Linux by default does not allow access to USB devices, you need to chmod corresponding pseudo-file in /dev (or write udev rule to make it happen automatically). So when one uses WebUSB (or any other usb software) without root, it won't work immediately.

junon 2y ago
Missing the point entirely. You must still enable USB support from the site before it can see or interact with anything.
- vbezhenar 2y ago
  It has nothing to do with sites. You are missing the point. To access USB device with Linux, any software, including browser, should have permission to access certain files in /dev.
  - junon 2y ago
    You visit a page. It asks for device access. You get a dialog box choosing the device that matches the filter the site wants. You can either choose a device or decline. Site does not see anything other than what you approve. What is difficult about understanding that?
    - deleted 2y ago
      [deleted]
    - deleted 2y ago
      [deleted]
    - kuschku 2y ago
      You're the one missing the forest for the trees. The security risk is not caused by websites, but by the fact that the browser can access your USB devices in the first place. By giving the browser access to your USB devices, the browser could act as a keylogger even when you're using other applications. Further, as there's no proper way to sandbox this, you wouldn't just be giving the browser keylogging capabilities, but any native app running under your user.

kuschku 2y ago

The browser itself shouldn't have access to raw devices, as that means giving all programs running under your user the ability to flash your keyboard firmware. The point of flatpak, wayland, etc is to prevent software from having access to everything. Making all USB devices readable and writable again circumvents the entire sandboxing concept of modern systems.