[GH-ISSUE #5926] vscode: cannot access USB debugger

gitea-mirror commented

2026-05-05 09:46:13 -06:00

Owner

Originally created by @ghost on GitHub (Jul 27, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5926

Hi all,

I am using Visual Studio Code to develop software, and would like to use the hardware debugger (ST-Link V2).

Unfortunately, the firejail locks the access of the software to the USB devices (message from the debug terminal):

libusb: error [get_usbfs_fd] File doesn't exist, wait 10 ms and try again
libusb: error [get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/003/007, errno=2
ST-Link enumeration failed

Error in initializing ST-LINK device.
Reason: ST-LINK DLL error.

This happens when I am starting VSCode from the desktop shortcut, but also when running

firejail /usr/bin/code

When starting with

firejail --noprofile /usr/bin/code

Everything works as it should. I tried removing line by line the default config (since something clearly locks the software access to the USB ports), but could not get it to work. Can you share some guidelines on what to check to fix the profile?

Is this considered a bug or should the final fix for the issue be placed in the code.local config?

Originally created by @ghost on GitHub (Jul 27, 2023). Original GitHub issue: https://github.com/netblue30/firejail/issues/5926 Hi all, I am using Visual Studio Code to develop software, and would like to use the hardware debugger (ST-Link V2). Unfortunately, the firejail locks the access of the software to the USB devices (message from the debug terminal): ```bash libusb: error [get_usbfs_fd] File doesn't exist, wait 10 ms and try again libusb: error [get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/003/007, errno=2 ST-Link enumeration failed Error in initializing ST-LINK device. Reason: ST-LINK DLL error. ``` This happens when I am starting VSCode from the desktop shortcut, but also when running ```bash firejail /usr/bin/code ``` When starting with ```bash firejail --noprofile /usr/bin/code ``` Everything works as it should. I tried removing line by line the default config (since something clearly locks the software access to the USB ports), but could not get it to work. Can you share some guidelines on what to check to fix the profile? Is this considered a bug or should the final fix for the issue be placed in the code.local config?

gitea-mirror

2026-05-05 09:46:13 -06:00

closed this issue
added the
notabug
label

gitea-mirror commented

2026-05-05 09:46:16 -06:00

Author

Owner

@ghost commented on GitHub (Jul 27, 2023):

When starting with firejail --noprofile /usr/bin/code Everything works as it should.

Great, that confirms the problem is in the code.profile and fixable.

I tried removing line by line the default config (since something clearly locks the software access to the USB ports), but could not get it to work. Can you share some guidelines on what to check to fix the profile?

First option that popped up as the culprit was private-dev. But I assume you've already tried removing that. The rather complex include logic for our VSCode profile sure doesn't make tasks like this any easier. And that affects your final question on where to place a fix or workaround. Let's put that aside for now and try to get a working code.profile. Based on your info that --noprofile does that, I've put together the below for you to test. Remember that using the --noprofile flag means that the default.profile options are used. Adding comments where these options stem from under /etc/firejail will hopefully help you solve the 'where do I place the fix' puzzle.

$ cat ~/.config/firejail/code.profile
# Firejail profile for Visual Studio Code
# This file is overwritten after every install/update
# Persistent local customizations
include code.local
# Persistent global definitions
include globals.local

# If your kernel allows the creation of user namespaces by unprivileged users
# (for example, if running `unshare -U echo enabled` prints "enabled"),
# you can uncomment lines that have 'from blink-common-hardened.inc.profile'.
# Doing so will harden the sandbox.

noblacklist ${HOME}/.config/Code
noblacklist ${HOME}/.config/Code - OSS
noblacklist ${HOME}/.vscode
noblacklist ${HOME}/.vscode-oss

noblacklist ${HOME}/.config/Electron # from electron-common.profile
noblacklist ${HOME}/.config/electron*-flag*.conf # from electron-common.profile

noexec /tmp

# Allows files commonly used by IDEs
include allow-common-devel.inc

include disable-common.inc # from blink-common.profile
include disable-programs.inc # from blink-common.profile

# allow-debuggers # doesn't seem to be needed if it works with --noprofile
apparmor # from blink-common.profile
#caps.drop all # from blink-common-hardened.inc.profile (cfr. default.profile)
caps.keep sys_admin,sys_chroot # from blink-common.profile
nodvd # from blink-common.profile
netfilter # from blink-common.profile
nogroups # from blink-common.profile
noinput # from blink-common.profile
#nonewprivs # from blink-common-hardened.inc.profile (cfr. default.profile)
#noroot # from blink-common-hardened.inc.profile (cfr. default.profile)
nosound
notv # from blink-common.profile
nou2f # from electron-common.profile
novideo # from electron-common.profile
#protocol unix,inet,inet6,netlink # from blink-common-hardened.inc.profile
#protocol unix,inet,inet6 # cfr. default.profile
#seccomp # cfr. default.profile
seccomp !chroot # from blink-common-hardened.inc.profile

private-cache # from blink-common.profile
#private-dev # from electron-common.profile - might break hardware debugging
private-tmp # from electron-common.profile

#restrict-namespaces # cfr. default.profile

Does that offer you a working baseline profile for VSCode as you use it - including any plugins etcetera? If so, you can try hardening it. If not, we'll have to redo :)

@ghost commented on GitHub (Jul 27, 2023): > When starting with firejail --noprofile /usr/bin/code Everything works as it should. Great, that confirms the problem is in the code.profile and fixable. > I tried removing line by line the default config (since something clearly locks the software access to the USB ports), but could not get it to work. Can you share some guidelines on what to check to fix the profile? First option that popped up as the culprit was `private-dev`. But I assume you've already tried removing that. The rather complex `include logic` for our VSCode profile sure doesn't make tasks like this any easier. And that affects your final question on where to place a fix or workaround. Let's put that aside for now and try to get a working code.profile. Based on your info that `--noprofile` does that, I've put together the below for you to test. Remember that using the --noprofile flag means that the `default.profile` options are used. Adding comments where these options stem from under /etc/firejail will hopefully help you solve the 'where do I place the fix' puzzle. ```sh $ cat ~/.config/firejail/code.profile # Firejail profile for Visual Studio Code # This file is overwritten after every install/update # Persistent local customizations include code.local # Persistent global definitions include globals.local # If your kernel allows the creation of user namespaces by unprivileged users # (for example, if running `unshare -U echo enabled` prints "enabled"), # you can uncomment lines that have 'from blink-common-hardened.inc.profile'. # Doing so will harden the sandbox. noblacklist ${HOME}/.config/Code noblacklist ${HOME}/.config/Code - OSS noblacklist ${HOME}/.vscode noblacklist ${HOME}/.vscode-oss noblacklist ${HOME}/.config/Electron # from electron-common.profile noblacklist ${HOME}/.config/electron*-flag*.conf # from electron-common.profile noexec /tmp # Allows files commonly used by IDEs include allow-common-devel.inc include disable-common.inc # from blink-common.profile include disable-programs.inc # from blink-common.profile # allow-debuggers # doesn't seem to be needed if it works with --noprofile apparmor # from blink-common.profile #caps.drop all # from blink-common-hardened.inc.profile (cfr. default.profile) caps.keep sys_admin,sys_chroot # from blink-common.profile nodvd # from blink-common.profile netfilter # from blink-common.profile nogroups # from blink-common.profile noinput # from blink-common.profile #nonewprivs # from blink-common-hardened.inc.profile (cfr. default.profile) #noroot # from blink-common-hardened.inc.profile (cfr. default.profile) nosound notv # from blink-common.profile nou2f # from electron-common.profile novideo # from electron-common.profile #protocol unix,inet,inet6,netlink # from blink-common-hardened.inc.profile #protocol unix,inet,inet6 # cfr. default.profile #seccomp # cfr. default.profile seccomp !chroot # from blink-common-hardened.inc.profile private-cache # from blink-common.profile #private-dev # from electron-common.profile - might break hardware debugging private-tmp # from electron-common.profile #restrict-namespaces # cfr. default.profile ``` Does that offer you a working baseline profile for VSCode as you use it - including any plugins etcetera? If so, you can try hardening it. If not, we'll have to redo :)

gitea-mirror commented

2026-05-05 09:46:17 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 27, 2023):

How do you test? Is the hardware plugged-in when you start code or do you need hotplug support?

noinput blocks /dev/usb IIRC. Or was it nou2f?

@rusty-snake commented on GitHub (Jul 27, 2023): How do you test? Is the hardware plugged-in when you start code or do you need hotplug support? `noinput` blocks /dev/usb IIRC. Or was it `nou2f`?

gitea-mirror commented

2026-05-05 09:46:17 -06:00

Author

Owner

@ghost commented on GitHub (Jul 27, 2023):

Hi, thank you for the responses.

@glitsj16 your config indeed works, however is very different to what is included in the default profile shipped in Fedora (it seems like it is the same profile as included in the repo).

@rusty-snake I run the cortex-debug command from code, with the st-link connected to the PC beforehand. I don't strictly need the hotplug, since code remembers the workspace's state. IDK if this is an issue with noinput or nou2f, since both are included in the config by @glitsj16. Or maybe my understanding of the config is wrong - I always thought that you include the parts you want to dissallow - so that when you don't have nou2f you can use them, but when you add them you can't. However, even if I comment out nou2f in the above config the debugger still works.

@ghost commented on GitHub (Jul 27, 2023): Hi, thank you for the responses. @glitsj16 your config indeed works, however is _very_ different to what is included in the default profile shipped in Fedora (it seems like it is the same profile as included in the repo). @rusty-snake I run the cortex-debug command from code, with the st-link connected to the PC beforehand. I don't strictly need the hotplug, since code remembers the workspace's state. IDK if this is an issue with noinput or nou2f, since both are included in the config by @glitsj16. Or maybe my understanding of the config is wrong - I always thought that you include the parts you want to dissallow - so that when you don't have nou2f you can use them, but when you add them you can't. However, even if I comment out `nou2f` in the above config the debugger still works.

gitea-mirror commented

2026-05-05 09:46:18 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 27, 2023):

However, even if I comment out nou2f in the above config the debugger still works.

So if you use the profile from above, it works no matter if nou2f is set or not?

@rusty-snake commented on GitHub (Jul 27, 2023): > However, even if I comment out nou2f in the above config the debugger still works. So if you use the profile from above, it works no matter if `nou2f` is set or not?

gitea-mirror commented

2026-05-05 09:46:18 -06:00

Author

Owner

@ghost commented on GitHub (Jul 27, 2023):

@glitsj16 your config indeed works, however is very different to what is included in the default profile shipped in Fedora (it seems like it is the same profile as included in the repo).

Correct, my above config reflects the current git state of VSCode-related profiles. If you're on 0.9.72 you don't have any of the changes introduced in 47e3c82ab5. IIRC the refactoring didn't flip, drop or add anything, just reshuffled existing options into different files. I'll have a look at 0.9.72 and post something you can integrate with that. Before doing so I wanted to know if my guess-work above could be confirmed to work :)

UPDATE:
Looks like you only need to ignore private-dev. You can do so on 0.9.72 either in code.local (only affecting VSCode) or in electron.local (affecting all electron-based software you use via firejail). The potential hardenings I referred to in the above example config can be added/tested by include electron-hardened.inc.profile, also in either one of the aforementioned files.

@ghost commented on GitHub (Jul 27, 2023): > @glitsj16 your config indeed works, however is very different to what is included in the default profile shipped in Fedora (it seems like it is the same profile as included in the repo). Correct, my above config reflects the current git state of VSCode-related profiles. If you're on 0.9.72 you don't have any of the changes introduced in https://github.com/netblue30/firejail/commit/47e3c82ab58b0d0c02066666aea3f7a04078c86b. IIRC the refactoring didn't flip, drop or add anything, just reshuffled existing options into different files. I'll have a look at 0.9.72 and post something you can integrate with that. Before doing so I wanted to know if my guess-work above could be confirmed to work :) UPDATE: Looks like you only need to `ignore private-dev`. You can do so on `0.9.72` either in `code.local` (only affecting VSCode) or in `electron.local` (affecting all electron-based software you use via firejail). The potential hardenings I referred to in the above example config can be added/tested by `include electron-hardened.inc.profile`, also in either one of the aforementioned files.

gitea-mirror commented

2026-05-05 09:46:19 -06:00

Author

Owner

@ghost commented on GitHub (Jul 28, 2023):

However, even if I comment out nou2f in the above config the debugger still works.

So if you use the profile from above, it works no matter if nou2f is set or not?

Yes, I tried both and it worked regardless.

@glitsj16 I added ignore private-dev in my code.local, and indeed it works fine. I also tried to include the hardened electron, but no luck, in fedora the chrome-common-hardened.inc.profile is not present, so I followed the commit you mentioned and added the hardening from blink-common-hardened.inc.profile to my local, keeping the original code.profile as the stock version from fedora. So this is my final code.local:

ignore private-dev

caps.drop all
nonewprivs
noroot
protocol unix,inet,inet6,netlink
seccomp !chroot

With this configuration all my extensions work, code has no access to ssh keys etc, and the hardware debugging works correctly.

From my perspective this issue is fixed, thank you very much for your support, I appreciate it. If you would like me to test something else or help in other way please let me know.

@ghost commented on GitHub (Jul 28, 2023): > > However, even if I comment out nou2f in the above config the debugger still works. > > So if you use the profile from above, it works no matter if `nou2f` is set or not? Yes, I tried both and it worked regardless. @glitsj16 I added ignore private-dev in my code.local, and indeed it works fine. I also tried to include the hardened electron, but no luck, in fedora the `chrome-common-hardened.inc.profile` is not present, so I followed the commit you mentioned and added the hardening from `blink-common-hardened.inc.profile` to my local, keeping the original `code.profile` as the stock version from fedora. So this is my final `code.local`: ```bash ignore private-dev caps.drop all nonewprivs noroot protocol unix,inet,inet6,netlink seccomp !chroot ``` With this configuration all my extensions work, code has no access to ssh keys etc, and the hardware debugging works correctly. From my perspective this issue is fixed, thank you very much for your support, I appreciate it. If you would like me to test something else or help in other way please let me know.

gitea-mirror commented

2026-05-05 09:46:19 -06:00

Author

Owner

@ghost commented on GitHub (Jul 29, 2023):

I also tried to include the hardened electron, but no luck, in fedora the chrome-common-hardened.inc.profile is not present

That's actually a known bug, which was fixed by the earlier mentioned 47e3c82ab5. On 0.9.72 you can safely exchange (the non-existing) chrome-common-hardened.inc.profile with (the existing) chromium-common-hardened.inc.profile in /etc/firejail/electron-hardened-inc.profile. After doing so you can include the hardened electron. That would be the more future-proof way to go here IMO.

From my perspective this issue is fixed, thank you very much for your support, I appreciate it. If you would like me to test something else or help in other way please let me know.

Thanks for the appreciation :)

Come to think of it, there actually is a quite important potential hardening to be made for the code.profile that you might want to test. You probably noticed that we've disabled it to be a fully whitelisting profile (which is the most hardened sandbox you can get with firejail):

bf8229dde7/etc/profile-a-l/code.profile (L8-L23)

If you're interested to help, that would be awesome. It's been untested for a while a now, so take your time, test VSCode for a while with a fully whitelisting profile and drop your observations in a new issue or discussion report when ready.

@ghost commented on GitHub (Jul 29, 2023): > I also tried to include the hardened electron, but no luck, in fedora the chrome-common-hardened.inc.profile is not present That's actually a known bug, which was fixed by the earlier mentioned https://github.com/netblue30/firejail/commit/47e3c82ab58b0d0c02066666aea3f7a04078c86b. On 0.9.72 you can safely exchange (the non-existing) `chrome`-common-hardened.inc.profile with (the existing) `chromium`-common-hardened.inc.profile in /etc/firejail/electron-hardened-inc.profile. After doing so you can include the hardened electron. That would be the more future-proof way to go here IMO. > From my perspective this issue is fixed, thank you very much for your support, I appreciate it. If you would like me to test something else or help in other way please let me know. Thanks for the appreciation :) Come to think of it, there actually is a quite important potential `hardening` to be made for the code.profile that you might want to test. You probably noticed that we've disabled it to be a fully whitelisting profile (which is the most hardened sandbox you can get with firejail): https://github.com/netblue30/firejail/blob/bf8229dde723d1c16b401d6d2d6154a0bf349eac/etc/profile-a-l/code.profile#L8-L23 If you're interested to help, that would be awesome. It's been untested for a while a now, so take your time, test VSCode for a while with a fully whitelisting profile and drop your observations in a new issue or discussion report when ready.

gitea-mirror commented

2026-05-05 09:46:20 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 29, 2023):

If you use it for more than just editing, these can be kept without discussion.

ignore include disable-devel.inc 
ignore include disable-exec.inc 
ignore include disable-interpreters.inc
ignore apparmor

@rusty-snake commented on GitHub (Jul 29, 2023): If you use it for more than just editing, these can be kept without discussion. ``` ignore include disable-devel.inc ignore include disable-exec.inc ignore include disable-interpreters.inc ignore apparmor ```

gitea-mirror commented

2026-05-05 09:46:20 -06:00

Author

Owner

@ghost commented on GitHub (Jul 31, 2023):

If you use it for more than just editing, these can be kept without discussion.
ignore include disable-devel.inc 
ignore include disable-exec.inc 
ignore include disable-interpreters.inc
ignore apparmor

Yes, from what I quickly tested enabling these options breaks some stuff, such as code compilation.

I included some options from the list of disabled ones in code.profile, found a few that probably can be safely included in the default configuration, will test them for a bit longer and give you back my feedback in the mentioned new issue.

Anyway I think that this one can be safely closed.

@ghost commented on GitHub (Jul 31, 2023): > If you use it for more than just editing, these can be kept without discussion. > > ``` > ignore include disable-devel.inc > ignore include disable-exec.inc > ignore include disable-interpreters.inc > ignore apparmor > ``` Yes, from what I quickly tested enabling these options breaks some stuff, such as code compilation. I included some options from the list of disabled ones in `code.profile`, found a few that probably can be safely included in the default configuration, will test them for a bit longer and give you back my feedback in the mentioned new issue. Anyway I think that this one can be safely closed.

gitea-mirror commented

2026-05-05 09:46:20 -06:00

Author

Owner

@kmk3 commented on GitHub (Jul 31, 2023):

(Re-closing as "not planned" since nothing was changed in firejail)

@kmk3 commented on GitHub (Jul 31, 2023): (Re-closing as "not planned" since nothing was changed in firejail)

Rows
Columns

[GH-ISSUE #5926] vscode: cannot access USB debugger #3133