mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1990] firefox: Yubikey u2f does not work if plugged in after launching (private-dev) #1341
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1341
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chiraag-nataraj on GitHub (Jun 11, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1990
So as documented in a bunch of issues (#1553, #1381),
private-devis broken with U2F. But I worked around that by using awhitelistinstead in my Firefox profile, and it works.However, I ran into a separate issue just now. The Yubikey is put into a different mode if I plug it in after starting the browser. So normally, it should use U2F authentication when requested. However, I think it gets stuck in OTP mode if I plug in the Yubikey after starting Firefox. If I plug it in before starting the browser, everything works as expected. But if I take it out and plug it back in later (say, because I want to authenticate another site), I run into the same issue. I will try removing my
whitelist /deventries to see if that fixes the issue.@chiraag-nataraj commented on GitHub (Jun 11, 2018):
Yup, commenting out the
whitelist /deventries fixes the problem. I'm not quite sure what's going on, since I whitelisted the required/dev/hidraw*devices.@chiraag-nataraj commented on GitHub (Jun 11, 2018):
Huh, I'm going to try whitelisting
/dev/usb/hiddev*@chiraag-nataraj commented on GitHub (Jun 11, 2018):
Okay, I see what's happening. When I whitelisted
/dev/usb/and/dev/usb/hiddev0, those devices existed upon startup. However, when I took the Yubikey out and plugged it back in,/dev/usb/hiddev0failed to reappear. Given that this file is created when the Yubikey is plugged in, this is probably why authentication no longer works when you take out the Yubikey and plug it back in.@netblue30 Do you have any idea why the whitelisted file is not re-appearing when it is re-created? Or rather, is there any way we can enable this? This would probably need some type of inotify system and a new command-line/profile option (something like
--watch=<file or directory>) which would watch for and react to changes. Thoughts?@Vincent43 commented on GitHub (Jun 11, 2018):
I think the problem is that firejail drops all privileges and can't modify sandbox after it was created. You have to either plug the token before starting sandbox or add
ignore private-devto local modifications.@chiraag-nataraj commented on GitHub (Jun 11, 2018):
Hmmm. I guess the problem is that with either
whitelistorprivate-dev, a new view of the filesystem is created which is effectively static. But if that's the case, why is/dev/usb/hiddev0disappearing after I disconnect it? Shouldn't the device file remain even if the device itself is disconnected?@Vincent43 commented on GitHub (Jun 11, 2018):
I think it's better to say that new view of filesystem is subset of the old view at the time it's created. So if existing device is deleted from host it's also deleted from sandbox but when new device is added to host the sandbox remains unaffected.
@chiraag-nataraj commented on GitHub (Jun 11, 2018):
Hmm, and this is a feature of mount namespaces I take it?
@chiraag-nataraj commented on GitHub (Jun 11, 2018):
Looking at the
mount_namespacesman page, couldn't we use theMS_SHAREDpropagation type? That is, use theMS_SHAREDpropagation type only on those specific files and directories that we whitelist (specifically forprivate-devorwhiteliston files/directories in/dev)?@netblue30 commented on GitHub (Jun 12, 2018):
That's the mount namespace, it has its own mount table. When you plug in a USB device it goes into the default mount table and it will not be propagated to all other namespaces.
There is this list of devices: https://github.com/netblue30/firejail/blob/master/src/firejail/fs_dev.c#L51
What if we add /dev/usb/hiddev* to the list by default? It will take care of the case when you already have the Yubikey plugged in. Then we add a --nou2f option similar to --nodvd, --novideo etc.
@chiraag-nataraj commented on GitHub (Jun 12, 2018):
Hmmm, that would go part-way towards solving this. But unlike with many other things, Yubikeys (and other U2F hardware devices) are things we repeatedly plug in and take out (leaving them in all the time can be a security risk, since it means that if the laptop is stolen, so is the key). As I mentioned above, there seem to be different mount propagation modes, and the behavior you're describing would be the default (slave?) mode iirc. Would it be possible to set up a shared mount for just the specific devices that are whitelisted? Or is that fundamentally impossible?
@chiraag-nataraj commented on GitHub (Jun 12, 2018):
Also, the key parts seem to actually be the things in
/dev/usb(i.e./dev/usb/hiddev0in my example above), since/dev/hidraw*seem to stay around even after I take out the Yubikey?@chiraag-nataraj commented on GitHub (Jun 12, 2018):
Huh, this is actually really interesting. I tried using
unshareto play around with mount namespaces. It seems that if I useunshareto create aprivate,slavemount namespace (throughsudo unshare -m --propagation slave /bin/bash), it still recognizes when the Yubikey is plugged back in (consistent with the manpage, which states that "When a mount point is a slave, mount and unmount events propagate into this mount point from the (master) shared peer group of which it was formerly a member. Mount and unmount events under this mount point do not propagate to any peer."That is, mount events from the master (in this case, that should be the global namespace, right?) should propagate into the slave namespace, while mount events in the slave shouldn't propagate back. But that seems to not be happening, even though this is a
private,slavenamespace. Does this have to do with the fact that we're creating mount namespaces for individual files?@netblue30 commented on GitHub (Jun 12, 2018):
Try the latest from main. I am bringing in by default /dev/usb in --private-bin:
2b4afcfb0a@chiraag-nataraj commented on GitHub (Jun 12, 2018):
Nope. I think we need to whitelist
/dev/hidraw*as well? I'm going to add it and try and report back.@chiraag-nataraj commented on GitHub (Jun 12, 2018):
Latest commit should fix it
78011fbc92@chiraag-nataraj commented on GitHub (Jun 12, 2018):
I suppose there's really nothing we can do about the device not re-appearing when we plug it back in, is there?
@chiraag-nataraj commented on GitHub (Jun 12, 2018):
Also added a
--nousboption to the command args andnousboption for the profile.197bcc86c1@chiraag-nataraj commented on GitHub (Jun 12, 2018):
If there's no way to solve the mount propagation issue, I think I can close this.
@kubrickfr commented on GitHub (Jul 3, 2018):
Would it be possible to add a udev rule to have the /dev/ file permanently in place even if the device is not connected?