<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0} p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi,<br></div><div><br></div><div>I am working on improving the security of the pcscd smartcard daemon by<br></div><div>running it with a system user instead of root (the pcsclite author<br></div><div>indicated support for this). I'd like to ask for advice on a particular point.<br></div><div><br></div><div># Background<br></div><div><br></div><div>For those who have never heard of it, pcscd[0][1] is part of a daemon/<br></div><div>shared library pair implementing the standard PC/SC API for<br></div><div>communicating with smartcards, this API is used on UNIX, Windows<br></div><div>and macOS. Smartcard readers almost all use the USB CCID (0x0b) class,<br></div><div>with some custom ones using the proprietary (0xff) class. The daemon<br></div><div>connects to smartcard readers using libusb. Clients connect via unix<br></div><div>socket. The daemon is socket-activated by default.<br></div><div><br></div><div>[0] <a href="https://pcsclite.apdu.fr/">https://pcsclite.apdu.fr</a><br></div><div>[1] <a href="https://github.com/LudovicRousseau/PCSC">https://github.com/LudovicRousseau/PCSC</a><br></div><div><br></div><div>Currently, this daemon is a big pile of C code running as root. The PC/SC<br></div><div>architecture involves the daemon calling into driver shared libraries to<br></div><div>perform the actual communication with the smartcard readers. These days<br></div><div>only one such is used widely, CCID[2][3].<br></div><div><br></div><div>[2] <a href="https://ccid.apdu.fr/">https://ccid.apdu.fr</a><br></div><div>[3] <a href="https://github.com/LudovicRousseau/CCID">https://github.com/LudovicRousseau/CCID</a><br></div><div><br></div><div>The CCID driver enumerates a long list of USB vendor/product pairs it<br></div><div>supports, and ignores others. This list includes all common smartcard readers.<br></div><div>It can be extended by end users.<br></div><div><br></div><div>[4] /usr/lib/pcsc/drivers/<a href="http://ifd-ccid.bundle/Contents/Info.plist">ifd-ccid.bundle/Contents/Info.plist</a><br></div><div><br></div><div># Switching to non-root user<br></div><div><br></div><div>The way my WIP patches implement this is:<br></div><div><br></div><div>- The pcsc package creates a `pcscd` system user/group.<br></div><div>- The ccid package installs udev rules making `pcscd` the owner/group of<br></div><div>all CCID devices (+ the few ones using the proprietary class by vendor/<br></div><div>product).<br></div><div><br></div><div>My question is, is it not considered "rude" for a particular package to<br></div><div>take ownership of these devices, when other processes might want to use<br></div><div>them as well? pcsclite is pretty standard but I'm not sure.<br></div><div><br></div><div>I noticed that the default udev rules already match smartcard reader<br></div><div>devices, set `ENV{ID_SMARTCARD_READER}=3D1` and add<br></div><div>`security-device` and `uaccess` tags.<br></div><div><br></div><div>The pcscd daemon cannot run as a user service and take advantage of the<br></div><div>uaccess tag because it needs to handle cross-user dynamic exclusive access<br></div><div>locking (transactions) and such, so it must run as a system service.<br></div><div><br></div><div>It seems better to me to give the device permissions to e.g. a `smartcard`<br></div><div>group instead of a `pcscd` group, and make `pcscd` user a member of that.<br></div><div>This is more neutral for other users. But how to coordinate this? It seems<br></div><div>inappeopriate for pcsclite to create such a group itself?<br></div><div><br></div><div>Another option I thought about is to only give the `pcscd` user ACL<br></div><div>permissions for the devices instead of full ownership, but I don't think udev<br></div><div>supports this?<br></div><div><br></div><div>Would appreciate any advice on best practices for this!<br></div><div><br></div><div>Ran<br></div></body></html>