Bug 19663

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.