Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
yubikey in sandboxed browser
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Wed Sep 11, 2024 6:11 pm    Post subject: yubikey in sandboxed browser Reply with quote

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
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3446
Location: Canada

PostPosted: Wed Sep 11, 2024 8:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Thu Sep 12, 2024 1:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Thu Sep 12, 2024 7:18 pm    Post subject: Reply with quote

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
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3446
Location: Canada

PostPosted: Thu Sep 12, 2024 7:32 pm    Post subject: Reply with quote

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
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3446
Location: Canada

PostPosted: Thu Sep 12, 2024 7:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Thu Sep 12, 2024 11:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22771

PostPosted: Fri Sep 13, 2024 12:44 am    Post subject: Reply with quote

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
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Fri Sep 13, 2024 2:51 am    Post subject: Reply with quote

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
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3446
Location: Canada

PostPosted: Fri Sep 13, 2024 6:56 pm    Post subject: Reply with quote

I learned a lot about ACL in this thread !
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Sat Sep 14, 2024 6:13 pm    Post subject: Reply with quote

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
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3446
Location: Canada

PostPosted: Sun Sep 15, 2024 1:00 am    Post subject: Reply with quote

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
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Mon Sep 16, 2024 4:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Fri Sep 20, 2024 1:33 am    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22771

PostPosted: Fri Sep 20, 2024 2:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Tue Oct 08, 2024 6:14 pm    Post subject: Reply with quote

Just an update here, it looks like this problem is broader than just the yubikey. I tried a webcam in the sandboxed browser, and the sandboxed user couldn't see that either.

I'm starting to think that the answer might be in writing a policykit rule for this. elogind uses policykit to determine what can and can't be allowed.
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Wed Oct 16, 2024 7:24 pm    Post subject: Reply with quote

Just an update here, I've tried adding a new rule to polkit:

Code:
polkit.addRule(function(action, subject) {
    if ( subject.isInGroup("plugdev")) {
            return polkit.Result.YES;
        }
    }
});


This rule is just for testing, since it is far too permissive and it would allow anyone in plugdev to do anything that polkit controls. Even with this rule in place, the sandboxed user doesn't have access to the yubikey device.

I put this rule in
Code:
/etc/polkit-1/rules.d/10-auth.rules


I'm going to keep working on this, but I'm new to polkit and elogind, so let me know if there's anything obvious I should try.
Back to top
View user's profile Send private message
wwdev16
n00b
n00b


Joined: 29 Aug 2018
Posts: 53

PostPosted: Sun Oct 20, 2024 9:08 pm    Post subject: Reply with quote

Do you have dev-libs/libfido2 installed? In the past I have found the udev rules that package installs were required to enable a yubikey 5 to work.

If you are just using the FIDO features in firefox I wouldn't expect you to need sys-apps/pcsc-lite[libusb]. If nothing else works you might try installing it.

Not that versed with the sound issues, but it might be that your sound devices can't be used by more than one user at a time unless you use an appropriately configured sound server such as media-video/pipewire. If lsof | grep larry shows any processes using the sound devices that might be an issue.
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Tue Oct 22, 2024 6:58 pm    Post subject: Reply with quote

wwdev16, that's an interesting idea about the sound, and easy to test. I just su'd into another user, and tried to play a sound file. It worked. That's not to say that all sound devices would work as a special user, though.

I don't have FIDO installed. I remember reading about it back when I first got the yubikey, but I didn't end up needed it for normal use. If it helps, this issue with the sandboxed user seems to come up regardless of the browser.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum