Best practice for giving a system daemon access to smartcard readers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I am working on improving the security of the pcscd smartcard daemon by
running it with a system user instead of root (the pcsclite author
indicated support for this). I'd like to ask for advice on a particular point.

# Background

For those who have never heard of it, pcscd[0][1] is part of a daemon/
shared library pair implementing the standard PC/SC API for
communicating with smartcards, this API is used on UNIX, Windows
and macOS. Smartcard readers almost all use the USB CCID (0x0b) class,
with some custom ones using the proprietary (0xff) class. The daemon
connects to smartcard readers using libusb. Clients connect via unix
socket. The daemon is socket-activated by default.

[0] https://pcsclite.apdu.fr
[1] https://github.com/LudovicRousseau/PCSC

Currently, this daemon is a big pile of C code running as root. The PC/SC
architecture involves the daemon calling into driver shared libraries to
perform the actual communication with the smartcard readers. These days
only one such is used widely, CCID[2][3].

[2] https://ccid.apdu.fr
[3] https://github.com/LudovicRousseau/CCID

The CCID driver enumerates a long list of USB vendor/product pairs it
supports, and ignores others. This list includes all common smartcard readers.
It can be extended by end users.

[4] /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist

# Switching to non-root user

The way my WIP patches implement this is:

- The pcsc package creates a `pcscd` system user/group.
- The ccid package installs udev rules making `pcscd` the owner/group of
all CCID devices (+ the few ones using the proprietary class by vendor/
product).

My question is, is it not considered "rude" for a particular package to
take ownership of these devices, when other processes might want to use
them as well? pcsclite is pretty standard but I'm not sure.

I noticed that the default udev rules already match smartcard reader
devices, set `ENV{ID_SMARTCARD_READER}=3D1` and add
`security-device` and `uaccess` tags.

The pcscd daemon cannot run as a user service and take advantage of the
uaccess tag because it needs to handle cross-user dynamic exclusive access
locking (transactions) and such, so it must run as a system service.

It seems better to me to give the device permissions to e.g. a `smartcard`
group instead of a `pcscd` group, and make `pcscd` user a member of that.
This is more neutral for other users. But how to coordinate this? It seems
inappeopriate for pcsclite to create such a group itself?

Another option I thought about is to only give the `pcscd` user ACL
permissions for the devices instead of full ownership, but I don't think udev
supports this?

Would appreciate any advice on best practices for this!

Ran

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux