Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to temporarily disconnect/disable a smart card to allow mapping into Crostini #122

Open
dragon788 opened this issue Jun 9, 2020 · 9 comments

Comments

@dragon788
Copy link

See more details on the Chromium group and the Crbug that actually appears to be partially by design behavior from the connector.

https://groups.google.com/a/chromium.org/d/msg/chromium-os-dev/7lvuQOVJbBo/JI0YnV7QAQAJ

https://bugs.chromium.org/p/chromium/issues/detail?id=1030778#c_ts1583002164

@liljenstolpe
Copy link

+1 this would solve a number of problems. It would be even better if it wouldn't take exclusive use, if possible. That would mean you wouldn't have to go frob it off, then frob it back on later.

@emaxx-google
Copy link
Collaborator

Changing the exclusive use would be pretty hard, both from the implementation perspective (involving significant rework of the CCID free software driver) and also from the practical usefulness (since a smart card middleware like CSSI will anyway keep a constantly opened connection to the reader/token in order to notify Chrome about changes).
Tackling this problem in a correct way might be related to the ongoing effort of converging the smart card stack on Chrome OS, like exposing it to PWAs. That'll be a long road though, especially for Crostini where smart cards haven't been prioritized yet.

So I'm afraid the manual disconnection would have to be our short- and middle-term solution.

@liljenstolpe
Copy link

The annoying thing here is that the ONLY place this doesn't work is in ChromeOS. It works with chrome browser on any other supported OS (BSD, Linux, Windows, and MacOS). For a company that touts 2-factor, physical tokens, and FIDO - it's a bit annoying that their OS doesn't actually allow this.

As much as I would like to continue to use ChromeOS/PixelBooks as a daily portable driver, I've been forced back to a Linux laptop to be able to access gitlab/github, my passwords (gopass), sign releases, etc. Basically, if you've bought into 2-factor GPG/SSH/FIDO, you have no realistic way of using ChromeOS unless EVERYTHING you do can be done via Chrome Apps/Browser.

@dragon788
Copy link
Author

The thing that gives me hope is that smart card sharing between multiple applications in a host/guest scenario is something that has been solved by VMware and Parallels and possibly Virtualbox already, so hopefully the incredibly clever folks at Google can work this out, especially with the decline of NaCl applications and the switch to WebASM for a lot of things.

@emaxx-google
Copy link
Collaborator

For the sharing smart card support between Crostini and the host OS, please file an issue into the Chromium tracker (https://crbug.com), which in particular tracks the Crostini-related tasks. This would need to be a separate effort, since there's no trivial way how this would work (as you cannot access the same USB device from two OS'es simultaneously, and since the standard PC/SC-Lite daemon always keeps an open connection to the reader).

@dragon788
Copy link
Author

It appears there might be a way to share access if one or the other process isn't "actively" using the smart card.

https://wiki.archlinux.org/index.php/GnuPG#Shared_access_with_pcscd

@emaxx-google
Copy link
Collaborator

It appears there might be a way to share access if one or the other process isn't "actively" using the smart card.

https://wiki.archlinux.org/index.php/GnuPG#Shared_access_with_pcscd

Thanks, but AFAICS that article talks about sharing access between multiple clients of the single pcscd daemon.

Here, in case of Chrome OS / Crostini, we have a different problem: it's a conflict between two different pcscd daemons. One daemon is running inside the Smart Card Connector app, and another one is the "standard" pcscd running inside the guest OS in Crostini.

@emaxx-google
Copy link
Collaborator

BTW, in case anyone would like to contribute the disconnect/disable workaround proposed in this issue (as on our side working on this issue isn't prioritized yet), the implementation could follow the pattern of the Libusb.ChromeLoginStateHook class that is also implementing a proxy for the USB API that dynamically hides devices based on some criteria. (The main difference is that this Libusb.ChromeLoginStateHook class shows/hides all devices at once, and that it doesn't have any user-visible UI/controls. But the implementation idea could be the same.)

@AnomalRoil
Copy link

FWIW, smart card access in Crotstini is now working for me on 92 beta, if I disable the Smart Card Connector app in chrome://extensions/ using the toggle and if I go to settings and attach the USB token to the Linux container under Settings -> Developers -> Linux development environment -> Manage USB devices (or using vmc in crosh).

It would still be nice if the Smart Card connector app could automagically release the smart card or even allow access / attachment to Crostini instead, tho.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants