Access control in PCSC
Add access control to PC/SC smart cards available in the system. Adding access control would (a) prevent unauthorized processes/users from reading data on a smart card, (b) prevent unauthorized processes/users from erasing a smart card, (c) prevent unauthorized processes/users from talking to the smart card firmware
- Name: Nikos Mavrogiannopoulos
- Email: firstname.lastname@example.org
- Release notes owner:
Add access control to PC/SC smart cards available in the system. Currently smart cards may provide their own access control for certain elements of a card such as a private key. Their access control method is typically a PIN, but can also be a biometric based one. That however, is not sufficient to prevent certain actions on the non-PIN protected elements. For example cards that provide a PKCS #15 filesystem can be modified by anyone that has access in the system (e.g., erased using pkcs15-init -E).
The default settings allowed should be similar to the default settings for hard disks, i.e., root and the user in console should be able to access the smart card.
Adding access control would
- prevent unauthorized processes/users from reading data on a smart card
- prevent unauthorized processes/users from erasing a smart card
- prevent unauthorized processes/users from talking to the smart card firmware
The way access control will be implemented is using polkit which is already being used to control access to hard disks. As smart cards share a lot with hard disks (e.g., a filesystem, and are inserted by the console user), sharing the same access control method is beneficial.
Benefit to Fedora
Users of Fedora would be able to use their smart cards securely even if the system is shared with other (non-privileged) users.
polkit support has to be added to PC/SC daemon. An initial version has already been developed and communicated upstream
- Proposal owners:
The polkit support has to be merged with the Fedora package. That requires changes to the pcsc daemon only, but indirectly all packages that potentially may use smart cards are affected (opensc, firefox, ...).
- Other developers:
Packages that use PC/SC smart cards must be checked that they work as expected after the access control change.
- Release engineering:
No coordination is required.
- Policies and guidelines:
If there is any security policy documentation should be updated to include the new policies on smart cards (I couldn't find any such documentation though)
If there are users that use smart cards not as console users but remotely would be affected by the change. It will require modifying the default policy configuration.
How To Test
Insert a (PC/SC) smart card into the system and from console type: $ pkcs15-init -E
The smart card should be erased.
Now if you ssh to localhost and type the same command an error should pop up.
There will not be user experience changes for local console users. Remote users will be unable to access a smart card by default.
Directly only opensc and coolkey depend on pcscd. However, indirectly any application that may use a PKCS #11 smart card will potentially depend on it. No changes are required to other packages.
- Contingency mechanism: (What to do? Who will do it?)
The backup plan if testing shows that there are issues with the new default configuration:
- Revert to a policy that is permissive as in the current situation
- Contingency deadline: Beta Freeze
- Blocks release: No