chromeos_smart_card_connector icon indicating copy to clipboard operation
chromeos_smart_card_connector copied to clipboard

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

Open dragon788 opened this issue 5 years ago • 9 comments

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

dragon788 avatar Jun 09 '20 05:06 dragon788

+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.

liljenstolpe avatar Jun 09 '20 16:06 liljenstolpe

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.

emaxx-google avatar Jun 09 '20 18:06 emaxx-google

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.

liljenstolpe avatar Jun 17 '20 19:06 liljenstolpe

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.

dragon788 avatar Jun 18 '20 13:06 dragon788

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).

emaxx-google avatar Jun 18 '20 14:06 emaxx-google

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

dragon788 avatar Aug 22 '20 01:08 dragon788

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 avatar Aug 22 '20 01:08 emaxx-google

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.)

emaxx-google avatar Aug 22 '20 01:08 emaxx-google

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.

AnomalRoil avatar Jul 09 '21 10:07 AnomalRoil