[Pcsclite-muscle] (possible) evolutions of pcsc-lite and libccid

[Frank Morgner]

Maybe you also want to take a look at this project for separating the
drivers from pcscd:

https://github.com/google/sandboxed-api

Regards, Frank.

Am Sa., 11. Mai 2024 um 19:01 Uhr schrieb Ludovic Rousseau
<ludovic.rousseau at gmail.com>:
>
> Hello Frank,
>
> Le sam. 11 mai 2024 à 17:01, Frank Morgner <frankmorgner at gmail.com> a écrit :
> > From your initial mail, I understand that you'd like to use the systemd sandbox to avoid security risk or privilege escalation. If I understand correctly, the Windows ecosystem has done this transition by pushing the driver implementation to.a seperate and dedicated user process (WUDF, see https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode). In the vsmartcard project, we this is implemented here for a PC/SC driver https://github.com/frankmorgner/vsmartcard/tree/master/virtualsmartcard/win32/BixVReader. Similarly (even though on a higher abstraction level), on macOS CryptoTokenKit the drivers for smart cards are implemented as app extensions, which are also running as seperated processes including the extension's requested access rights via entitlements.
> >
> > So if you want to leverage systemd sandbox, I think pcscd should have its own sandbox that is seperated from the sandbox which is used by the specific reader driver. This way, you could manage the permissions of pcscd seperate from the permissions that the reader driver needs (e.g. access to USB for libccid compared to access to network for virtual smart card/vpcd). Techincally speaking, for every driver you'd create a new sandboxed process that loads the the actual shared object file of the driver. The object file would not need to be changed (i.e. https://pcsclite.apdu.fr/api/group__IFDHandler.html). The sandboxed driver process and the sandboxed pcscd process need to agree on some IPC to communicate with each other (i.e. from ICC Resource Manager to IFD Handler, see PC/SC pt. 1). Since you would create both type of processes (and the related IPC) within the PCSC-Lite, the only additional work for the driver would be to *explicitly* specify the needed permissions, preferably compatible with the systemd format.
>
> Yes, that is the idea.
> My goal was to use a systemd sandbox for pcscd and its drivers as an
> easy-to-implement solution. But that may not be possible, or the
> sandbox will be minimal like no access to user's files.
>
> The multi-process architecture (also proposed by Martin) with each
> driver in its own sandbox is much better. But I won't do it unless
> someone is willing to sponsor development. A willing company?
>
> Next step is to read systemd (or something else) documentation.
> If you have good pointers please share them.
>
> Thanks all for your comments
>
> --
>  Dr. Ludovic Rousseau