[Pcsclite-muscle] systemd pcscd.service hardening

[Ran Benita]

On Mon, Jan 20, 2025, at 22:50, Ludovic Rousseau wrote:
> Hello Ran,
>
> Le dim. 19 janv. 2025 à 21:58, Ran Benita <ran at unusedvar.com> a écrit :
>>
>> On Sun, Jan 19, 2025, at 17:48, Ludovic Rousseau wrote:
>> > # System Call Filtering
>> > SystemCallFilter=@system-service
>> > SystemCallFilter=~@resources @privileged
>>
>> In my experience, removing @privileged isn't worth it, there's too much code making occasional use
>> of e.g. fchown, and debugging seccomp kills is not easy for ordinary users.
>
> My request is exactly to ask people to test this configuration.

I'll be testing it :)

> If removing @privileged is problematic I will remove it.

I suppose this is sensible.

> I don't understand "debugging seccomp kills is not easy for ordinary users".

If the process uses a blocked system call, the process is immediately killed with signal SIGSYS. There
will be no logs from pcscd about it, only an obscure Linux audit log and a coredump. Someone who
knows what to look for can definitely figure it out, but ordinary users will not.

It is possible to configure systemd to make the system call return an error (e.g. EPERM) instead of
sending SIGSYS, but that has its own set of worse issues, so the signal is usually preferred.

>> The largest sandboxing omission is of course - running as a non-root user. As long as pcscd is running
>> as root, it'd be very hard to avoid sandbox escapes. What are the reasons that pcscd needs root?
>>
>> The biggest one I know of is access to (USB) devices, but I think the IFD handlers can install udev
>> rules giving the pcscd user (and only the pcscd user) access to their relevant devices (and only their
>> relevant devices).
>>
>> Are there other reasons?
>
> A long time ago (in pcsc-lite version 1.6.5) I tried to run pcscd as
> the pcscd user with udev rules to set the access rights
> See "pcscd auto start" https://blog.apdu.fr/posts/2010/09/pcscd-auto-start/
>
> The pcscd process was started by the libpcsclite.so.1 library
> It was added in
> https://github.com/LudovicRousseau/PCSC/commit/87f64dd767b2277223f79941b317119d16df9468
> (Nov 27, 2009)
>
> This was removed in
> https://github.com/LudovicRousseau/PCSC/commit/244664b6b31e723728d409dd178ed11722d83a84
> (Nov 14, 2011) to use systemd instead.
> The plan was to work on restrictions and run pcscd process as a normal
> user again.
> We also had to convert all the drivers to use a udev rule file.
> But motivation and time was missing.
>
>> (I did a web search now, and found your old blog post about this:
>> https://ludovicrousseau.blogspot.com/2010/12/configuring-your-system-for-pcscd-auto.html
>> but this is no longer present, so I guess it didn't work out?)
>
> The comment from
> https://github.com/LudovicRousseau/PCSC/commit/244664b6b31e723728d409dd178ed11722d83a84
> is:
> " Remove pcscd autostart feature
>
> The auto start feature (launch pcscd from the library if not already
> running) was a fragile code with some issues. This service is far
> better implemented by systemd.
> Thanks to Kalev Lember for pushing the systemd patches. "
>
> But I do not remember the details of what were the problems 15 years ago.
> I should have been more explicit in the commit message.

Thanks for the details.

I'm willing to work on this if you are willing. A rough plan:

1. Make an experimental PCSC branch which runs as a pcscd user instead of root on Linux.
Combine with current experiment, do it concurrently, or do it after?

2. Make an experimental CCID branch which installs the appropriate udev rules on Linux.
Hopefully it's possible to make this conditional on the existence of a pcscd user, so there is
no hard dependency on (1).
Writing a rule that matches all USB CCID devices should be possible (you already show it in
your blog). I'm less familiar with any other device types that CCID driver supports, like PCI or
serial, hopefully you could fill me in on those.

3. Announce the intention to change pcscd to not run as root, specifically mentioning that
custom drivers will no longer have access to devices by default, and will need to install
appropriate udev rules giving the pcscd user permission to their devices. Explain how
to test.

4. Document how to make pcscd run as root again (place a systemd drop-in file), as a last
resort.

5. After some time, if testing went well, release it.

Ran