Created attachment 22113 [details] [review] hal-smart-card.patch Policy for Smart Card Readers is needed, as none of existing policies could fit (however one could expect, that Smart Card readers and fingerprint readers will use the same policy). The keyword may include security tokens (smart tokens). Patch is attached. Subjects for discussion: This area is much wider than this patch presents. It's a subject of discussion, whether HAL should define more "categories", or discriminate between these devices using "capabilities", introduce more keywords, or ignore differences. Device classes: Class 1: Reader only. Class 2: Reader and keyboard for PIN (PIN never reaches the computer). Class 3: Reader, keyboard for PIN and secure display to see what is going to be signed (PIN never reaches the computer, trusted display). Wireless: Supports wireless protocol. Device types: ISO: Supports replace-able ISO cards, can support SIM cards via adapters. SIM: Token with replace-able smart SIM cards. token: Chip is hard binded with the USB connector. Optional additional features: One device may support more readers (e. g. Class 3 + wireless). fingerprint reader (don't mix with standard fingerprint reader, scan from this reader never reaches the computer) multiple readers in one (different slots can have different class) autonomous reader (can log transactions without computer, then reply them at once) ... Other similar device types: MiFare chip readers (wireless) RFID readers (wireless) resonator label detector & deactivator (wireless) Magnetic card readers (typically serial port with special permissions) Fingerprint readers (already in HAL) Retina scanners And other card types that may be supported: Generic chip cards (contains processor, but cryptographis software is not uploaded), 90% of them may be handled by ISO/SIM readers. Serial EEPROMs cards Bit-burning PROM cards Depending on usage, these devices are accessed via a daemon (e. g. pcscd, openct) or directly (special applications). Possible alternative definition (one of many choices): info.category: security info.capabilities: security.chip_card.iso security.smart_card.class3
Downstream bug reference: https://bugzilla.novell.com/show_bug.cgi?id=467255 Smart Card mailing list reference: http://www.opensc-project.org/pipermail/opensc-devel/2009-January/011585.html
I do not see the link between the proposal and the "Downstream bug reference: https://bugzilla.novell.com/show_bug.cgi?id=467255" They are two completly different problems.
Yes, original bug was completely different, but fix requires a keyword (or keywords) for HAL to define smart_card_policy. As shows discussion in the list <allow_active>yes</allow_active> may be a bad idea.
"but fix requires a keyword (or keywords) for HAL to define smart_card_policy" I don't think so. But I still do not know what the exact problem is.
Created attachment 22385 [details] [review] proposed patch for iso7816 namespace and ACL policy After discussion at IRC, I would propose this patch to add the iso7816 namespace. It includes also updates for the spec. For a smart card reader we would have: - info.capabilities = {'iso7816', iso7816.smart_card_reader} - info.category = 'iso7816.smart_card_reader' For a smart token: - info.capabilities = {'iso7816', iso7816.smart_token} - info.category = 'iso7816.smart_token'
The only think I'm not sure about is, if we should really call the namespace iso7816. We have already a biometric namespace (which contains a subnamespace for fingerprintreader). Maybe we should replace 'iso7816' with 'security'?
Consensus from disussion with upstream: - Do not use keyword "iso7816" as a primary keyword. "smart_card_reader" is less cryptic for users. (And it's easy to understand, that USB crypto token is "smart card reader + smart card in one".) - Do not use "smart_token". "crypto_token" or "usb_crypto_token" is more appropriate. - Capabilities keyword for reader with slot(s) is not yet defined. Maybe "smart_card_slot" capabilities would fit. - Do not try to unify ISO 7816 devices (smart_card_reader) with other "security" technologies (magnetic card readers, iButtons...). They have very few common things: the form factor, some or use cases, but they do not share the technology.
Okay, then I would propose smart_card is the common namespace for these devices. I wouldn't use smart_card_reader, since it's then hard to differ between the different types (smart_card_reader/crypto_token/smart_card_slot) and I would like to prevent capabilities like: smart_card_reader.smart_card_reader. We can use the smart_card capability as a common match for the ACL rules. For a smart card reader we would have: - info.capabilities = {'smart_card', smart_card.smart_card_reader} - info.category = 'smart_card.smart_card_reader' For a smart token: - info.capabilities = {'smart_card', smart_card.crypto_token} - info.category = 'smart_card.crypto_token' For smart card slot: - info.capabilities = {'smart_card', smart_card.smart_card_slot} - info.category = 'smart_card.smart_card_slot' @Stanislav: if this is okay for you, I would commit it to git, so that I can release HAL 0.5.12 now.
It's a bit impractical. Both should have a common category. There are devices, which can be indentified as one of these devices, but the driver cannot provide information, which one of them it is. It typically happens for unknown USB CCID devices. => Query would need to check for three "category" slots. smart_card and smart_card_reader are different categories: Card reader is a device, that allows to read cards or provides an interface for token. This category can be mapped to and USB or derial device node. Smart card is a device, that contains the chip. It is not possible to map it in HAL yet: there is no udev insert/removal event, there is no kernel driver. The whole detection runs in user space, and even insert/removal events are not yet implemented. The same is valid for slots: More slots is mapped to a single kernel device. Only user space daemon can recognize slots. Please save "smart_card" category for possible future mapping of smart cards instead of using it for readers. And let "smart_card_slot" category reserved for future use as well. After a discussion with upstream, abuse of "smart_card_reader" for crypto tokens seems to be acceptable: I guess this would be better: For a smart card reader we would have: - info.capabilities = {'smart_card_reader', 'smart_card_reader.card_reader'} - info.category = 'smart_card_reader' For a crypto token: - info.capabilities = {'smart_card_reader', 'smart_card_reader.crypto_token'} - info.category = 'smart_card_reader' For unknown (reader or token) crypto device: - info.capabilities = {'smart_card_reader'} - info.category = 'smart_card_reader' Let's not define slots and cards for now, as the definition above would be sufficient for PolicyKit.
I commited this to git: - spec: http://cgit.freedesktop.org/~dkukawka/hal/commit/?id=0f2d03c492f32428e8ca3a72ce52ecf2fcdfa780 - ACL/device-access policy: http://cgit.freedesktop.org/~dkukawka/hal/commit/?id=7123ef9a78c8c6b504e6ba98218fc556641a458c I merge it into the hal repo with the next sync.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.