| View previous topic :: View next topic |
| Author |
Message |
jyoung
Guru
Joined: 20 Mar 2007
Posts: 464
|
 Posted: Wed Sep 11, 2024 6:11 pm Post subject: yubikey in sandboxed browser |
 |
|
I've been following this tutorial to setup a sandbox for my web browser
https://wiki.gentoo.org/wiki/Simple_sandbox#Install_and_configure_sudo
This type of sandboxing launches the browser through a dummy user account. I've added then additional feature that, between launches of the browser, the dummy user's home folder is wiped (so, no hidden cookies, etc.)
Nearly everything is working, but I'm having trouble using a yubikey through the sandboxed browser. For those you've not heard of it, a yubikey is a usb stick that acts as a 2nd factor in 2-factor authentication. I use it a lot when logging into stuff for work. It works fine when used through the non-sandboxed browser.
To try and solve this, I also added the dummy user's account to the usb group, but no luck. I'd be grateful for any help!
Also, the "Networking & Security" forum seemed the right place for this thread, but do correct me if I ought to have posted it somewhere else. |
|
| Back to top |
|
 |
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3382
Location: Canada
|
| Posted: Wed Sep 11, 2024 8:02 pm Post subject: |
|
|
So when you insert the yubikey, who is the owner and what are the permissions on the USB device ?
And, perhaps a strange question, is your keyboard (not mouse) is working in sandbox browser ? |
|
| Back to top |
|
|
jyoung
Guru
Joined: 20 Mar 2007
Posts: 464
|
| Posted: Thu Sep 12, 2024 1:33 pm Post subject: |
|
|
Interesting, the yubikey shows up as two devices. Here are the full stats:
| Code: |
ls /dev/hidraw2 /dev/usb/hiddev0 -l
crw-rw----+ 1 root root 246, 2 Sep 12 09:30 /dev/hidraw2
crw------- 1 root root 180, 96 Sep 12 09:30 /dev/usb/hiddev0
|
I just checked, and my keyboard (which is also usb) does work in the browser.
I also checked the device ownership on another similar computer, and there the yubikey shows up as a single device owned by plugdev. On this computer, there is no plugdev group (or at least the regular user isn't a part of plugdev). |
|
| Back to top |
|
|
jyoung
Guru
Joined: 20 Mar 2007
Posts: 464
|
| Posted: Thu Sep 12, 2024 7:18 pm Post subject: |
|
|
This is how it shows up on the other similar computer
| Code: | ls -l /dev/hidraw4
crw-rw----+ 1 root plugdev 244, 4 Sep 12 15:17 /dev/hidraw4
|
Here, the normal user is in plugdev. The yubikey does work on this computer as well, although I haven't tried the sandbox yet.[/quote] |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3382
Location: Canada
|
| Posted: Thu Sep 12, 2024 7:32 pm Post subject: |
|
|
| jyoung wrote: | Interesting, the yubikey shows up as two devices. Here are the full stats:
| Code: |
ls /dev/hidraw2 /dev/usb/hiddev0 -l
crw-rw----+ 1 root root 246, 2 Sep 12 09:30 /dev/hidraw2
crw------- 1 root root 180, 96 Sep 12 09:30 /dev/usb/hiddev0
|
I just checked, and my keyboard (which is also usb) does work in the browser.
I also checked the device ownership on another similar computer, and there the yubikey shows up as a single device owned by plugdev. On this computer, there is no plugdev group (or at least the regular user isn't a part of plugdev). |
I asked about keyboard because yubikey is supposed to present itself as a keyboard (that is why it is HID device). If you compare settings that your real keyboard gets, are their any differences ?
I wonder that your hid devices created are writeable/readable only for root user and root group. Could it be that it is not sufficient for yubikey ? What if you just by hand change the permissions to 666 ( chmod 666 /dev/hidraw2 and same for hiddev0, you need to be root to do it) ? |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3382
Location: Canada
|
| Posted: Thu Sep 12, 2024 7:33 pm Post subject: |
|
|
| jyoung wrote: | This is how it shows up on the other similar computer
| Code: | ls -l /dev/hidraw4
crw-rw----+ 1 root plugdev 244, 4 Sep 12 15:17 /dev/hidraw4
|
Here, the normal user is in plugdev. The yubikey does work on this computer as well, although I haven't tried the sandbox yet. |
[/quote]
I guess your fake user will need to be in plugdev as well |
|
| Back to top |
|
|
jyoung
Guru
Joined: 20 Mar 2007
Posts: 464
|
| Posted: Thu Sep 12, 2024 11:02 pm Post subject: |
|
|
Okay, I tried adding both the regular user and the sandbox user to plugdev, but no luck. I also tried chmod 666 on both of the devices, but again no luck.
It looks like the plugdev group did exist, even if the regular user wasn't previously apart of it. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22419
|
| Posted: Fri Sep 13, 2024 12:44 am Post subject: |
|
|
| That trailing + in the ls output suggests to me that ACLs are in use, which could happen if (e)logind is granting the console user extra permissions. |
|
| Back to top |
|
|
jyoung
Guru
Joined: 20 Mar 2007
Posts: 464
|
| Posted: Fri Sep 13, 2024 2:51 am Post subject: |
|
|
Interesting, I didn't know what that was! A web search reveals a few tools to work with access control lists, and perhaps this is a significant clue:
| Code: | getfacl /dev/usb/hiddev0
getfacl: Removing leading '/' from absolute path names
# file: dev/usb/hiddev0
# owner: root
# group: root
user::rw-
group::---
other::---
|
That looks weird, as if only root can access this device. But when I query the other device name that the yubikey seems to have
| Code: |
getfacl /dev/hidraw2
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw2
# owner: root
# group: root
user::rw-
user:normal_user:rw-
group::---
mask::rw-
other::---
|
Now, that makes some sense. The normal_user is able to use the yubikey.
How does elogind (or whichever daemon controls the access lists) know to pin this device to the normal_user? For example, what if I wasn't logged into the workstation, but I was logged in via ssh, and a friend came and put the yubikey into the workstation? Not that I plan to do that, I'm just curious.
Getting back to the problem, it looks like setfacl can be used to add and remove users from access lists for files and devices. Here's a procedure that does allow the sandbox user to use the yubikey:
launch the web browser in the sandbox
plug in the yubikey so that the device appears
look for new devices that the normal user has access to via ACLs
as root, grant the sandbox user access
| Code: | | setfacl -m u:sandboxed_user:rwx /dev/hidraw2 |
That succeeds, but it's not great since it requires the user (me) to execute a command as root just to get access to the yubikey. And worse, it's not persistent, so the command as root would need to be executed every time the yubikey is unplugged (I just tried it). It's also really specific to the details, like the device name. Is there a best practice? Maybe I could grant the sandboxed user access to some or all of the regular user's ACLs? Maybe just a subset of the ACLs that are associated with USB devices? |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3382
Location: Canada
|
| Posted: Fri Sep 13, 2024 6:56 pm Post subject: |
|
|
| I learned a lot about ACL in this thread ! |
|
| Back to top |
|
|
jyoung
Guru
Joined: 20 Mar 2007
Posts: 464
|
| Posted: Sat Sep 14, 2024 6:13 pm Post subject: |
|
|
I've been thinking about this, and perhaps the solution is to set all HID devices for near universal access? This would weaken the security, but as far as I can tell it would be only in oddball cases, like if someone ssh'd in they would be able to read keystrokes.
I'm guessing that removing ACL support from elogind would prevent event the normal user from accessing the device, yes? That seems likely since the device is owned by root. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3382
Location: Canada
|
| Posted: Sun Sep 15, 2024 1:00 am Post subject: |
|
|
| jyoung wrote: | I've been thinking about this, and perhaps the solution is to set all HID devices for near universal access? This would weaken the security, but as far as I can tell it would be only in oddball cases, like if someone ssh'd in they would be able to read keystrokes.
I'm guessing that removing ACL support from elogind would prevent event the normal user from accessing the device, yes? That seems likely since the device is owned by root. |
Well, one would think that without ACL simple Unix user:group will suffice ? i.e if device is created with root:ybikey ownership and both regular user and fake one is in ybikey group. I wonder if you can teach udev to create device with needed ownership or ACLs ? |
|
| Back to top |
|
|
jyoung
Guru
Joined: 20 Mar 2007
Posts: 464
|
| Posted: Mon Sep 16, 2024 4:48 pm Post subject: |
|
|
That's an interesting idea. If I remove elogind, would the device show up as being owned by root:plugdev? If yes, then adding the both the fake and regular user to plugdev would probably work. I'll try this experiment, and report back.
However, I'm seeing that a lot of packages depend on elogind. For some, it's optional, but less so for others, so I don't think this will be a long-term solution. It seems like more fine-grain control over elogind or ACLs is probably the answer.
The other solution I've considered, which would surely work although it's a bit of a hack, is to have a daemon process running as root that waits for this device to appear, and then add the fake user to the ACL. |
|
| Back to top |
|
|
jyoung
Guru
Joined: 20 Mar 2007
Posts: 464
|
| Posted: Fri Sep 20, 2024 1:33 am Post subject: |
|
|
| Okay, today I removed elogind and rebooted. The permissions on the device /dev/hidraw2 no longer included the +, so no ACLs. But, in this case neither the real nor fake user was able to access it. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22419
|
| Posted: Fri Sep 20, 2024 2:31 pm Post subject: |
|
|
| Right, the ACL from elogind is why your main user can use it. Either make elogind put both users on the ACL, or use a sandboxing solution that does not involve using a separate UID. I don't know how to make elogind behave differently here. |
|
| Back to top |
|
|
|
Networking & Security
