Discussion:
using polkit
Nikos Mavrogiannopoulos
2013-12-17 15:41:27 UTC
Permalink
Hello,
This patch adds polkit [0] support to pcscd, if the --with-polkit
configure option is specified. That allows more fine grained access
control to smart cards (e.g., only console users can access the card
and so on). It is a preliminary patch and the pcscd option with
very crude access control (allowed to access or not). Please let me
know of any comments.

regards,
Nikos

[0].
http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
h***@ecsec.de
2013-12-17 21:27:43 UTC
Permalink
Hi,

maybe i miss something, but what would be a normal use case?

Mostly a smart card has own mechanisms for access control e.g. by using pin,
biometrics or so for operations like sign.
In case of private keys it is mostly forbidden to read them per default.

Would be nice if you could explain your intentions in more detail.

Thanks in advance

Best regards

Hans-Martin
Post by Nikos Mavrogiannopoulos
Hello,
This patch adds polkit [0] support to pcscd, if the --with-polkit
configure option is specified. That allows more fine grained access
control to smart cards (e.g., only console users can access the card
and so on). It is a preliminary patch and the pcscd option with
very crude access control (allowed to access or not). Please let me
know of any comments.
regards,
Nikos
[0].
http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
_______________________________________________
Muscle mailing list
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Nikos Mavrogiannopoulos
2013-12-18 09:15:17 UTC
Permalink
Post by h***@ecsec.de
Hi,
maybe i miss something, but what would be a normal use case?
Mostly a smart card has own mechanisms for access control e.g. by
using pin, biometrics or so for operations like sign.
In case of private keys it is mostly forbidden to read them per default.
Hello,
Indeed smart cards _may_ have some access control method (but they are
not required to). The smart card access control currently is very
coarse (as I can erase every smart card in the system without any
special permissions), and several files on the card like certificates are
almost never protected.

What the patch ensures is that only admin-authorized processes can talk
to the hardware. That means:
* Only authorized processes can extract the public information in the
card.
* Only authorized processes can erase the card.
* Only authorized processes can talk to the card firmware (cards may
have bugs as any other kind of software).

Moreover, authorization policy is tied to the system processes rather
than being an external process that depends on the smart card in
use. For example, a PIN-enabled smart card can never distinguish a
local user from a console one, however polkit policies can.

regards,
Nikos
Ludovic Rousseau
2014-01-04 20:57:35 UTC
Permalink
Post by Nikos Mavrogiannopoulos
Post by h***@ecsec.de
Hi,
maybe i miss something, but what would be a normal use case?
Mostly a smart card has own mechanisms for access control e.g. by
using pin, biometrics or so for operations like sign.
In case of private keys it is mostly forbidden to read them per default.
Hello,
Indeed smart cards _may_ have some access control method (but they are
not required to). The smart card access control currently is very
coarse (as I can erase every smart card in the system without any
special permissions), and several files on the card like certificates are
almost never protected.
What the patch ensures is that only admin-authorized processes can talk
* Only authorized processes can extract the public information in the
card.
* Only authorized processes can erase the card.
* Only authorized processes can talk to the card firmware (cards may
have bugs as any other kind of software).
Moreover, authorization policy is tied to the system processes rather
than being an external process that depends on the smart card in
use. For example, a PIN-enabled smart card can never distinguish a
local user from a console one, however polkit policies can.
I am still not convinced that Policy Kit is a good solution for the
problems you describe.

If the card can be erased or modified without any previous
authentication (PIN or secure message) then that is the problem of the
card (or card provider).

If you want to avoid a remote user to use a PIN protected card the
best is to use a pinpad reader with a firewall. The PIN will only be
entered using the pinpad. Any PIN verification command will be
rejected by the reader firewall.

But maybe I missed something.

Regards,
--
Dr. Ludovic Rousseau
Nikos Mavrogiannopoulos
2014-01-06 09:24:40 UTC
Permalink
Post by Ludovic Rousseau
Post by Nikos Mavrogiannopoulos
Hello,
Indeed smart cards _may_ have some access control method (but they are
not required to). The smart card access control currently is very
coarse (as I can erase every smart card in the system without any
special permissions), and several files on the card like certificates are
almost never protected.
What the patch ensures is that only admin-authorized processes can talk
* Only authorized processes can extract the public information in the
card.
* Only authorized processes can erase the card.
* Only authorized processes can talk to the card firmware (cards may
have bugs as any other kind of software).
Moreover, authorization policy is tied to the system processes rather
than being an external process that depends on the smart card in
use. For example, a PIN-enabled smart card can never distinguish a
local user from a console one, however polkit policies can.
I am still not convinced that Policy Kit is a good solution for the
problems you describe.
I agree there may be other solutions as the ones you suggest below, but
they require changing the hardware. Access control with polkit works
with any smart card and any smart card access control method. Also the
3rd point I make (access to the card firmware) cannot be solved by
additional hardware, but is solved with polkit.
Post by Ludovic Rousseau
If the card can be erased or modified without any previous
authentication (PIN or secure message) then that is the problem of the
card (or card provider).
All the smart cards I ever had can be erased by anyone in the system
using "pkcs15-init -E". So using polkit there will allow the
administrator of the system to define the "anyone" part.
Post by Ludovic Rousseau
If you want to avoid a remote user to use a PIN protected card the
best is to use a pinpad reader with a firewall. The PIN will only be
entered using the pinpad. Any PIN verification command will be
rejected by the reader firewall.
Or I can use polkit :) The latter requires no additional hardware and is
already used for access control (to access hard disks) in most systems.

In general administrating a system doesn't always imply selection of the
authenticating tokens. Typically the tokens are fixed and the
administrator tries to make the best use of the system access controls
to prevent misuse. In 99% of the cases a smart card is used
interactively from the guy sitting on the PC and currently there is no
way to enforce that.

regards,
Nikos
Ludovic Rousseau
2014-01-06 09:44:48 UTC
Permalink
Post by Nikos Mavrogiannopoulos
Post by Ludovic Rousseau
Post by Nikos Mavrogiannopoulos
Hello,
Indeed smart cards _may_ have some access control method (but they are
not required to). The smart card access control currently is very
coarse (as I can erase every smart card in the system without any
special permissions), and several files on the card like certificates are
almost never protected.
What the patch ensures is that only admin-authorized processes can talk
* Only authorized processes can extract the public information in the
card.
* Only authorized processes can erase the card.
* Only authorized processes can talk to the card firmware (cards may
have bugs as any other kind of software).
Moreover, authorization policy is tied to the system processes rather
than being an external process that depends on the smart card in
use. For example, a PIN-enabled smart card can never distinguish a
local user from a console one, however polkit policies can.
I am still not convinced that Policy Kit is a good solution for the
problems you describe.
I agree there may be other solutions as the ones you suggest below, but
they require changing the hardware. Access control with polkit works
with any smart card and any smart card access control method. Also the
3rd point I make (access to the card firmware) cannot be solved by
additional hardware, but is solved with polkit.
Post by Ludovic Rousseau
If the card can be erased or modified without any previous
authentication (PIN or secure message) then that is the problem of the
card (or card provider).
All the smart cards I ever had can be erased by anyone in the system
using "pkcs15-init -E". So using polkit there will allow the
administrator of the system to define the "anyone" part.
I guess you only have PKCS#15 cards with default (known) transport keys.

You can't reinitialize a correctly configured smart card. Try to erase
a SIM or banking card.
Post by Nikos Mavrogiannopoulos
Post by Ludovic Rousseau
If you want to avoid a remote user to use a PIN protected card the
best is to use a pinpad reader with a firewall. The PIN will only be
entered using the pinpad. Any PIN verification command will be
rejected by the reader firewall.
Or I can use polkit :) The latter requires no additional hardware and is
already used for access control (to access hard disks) in most systems.
In general administrating a system doesn't always imply selection of the
authenticating tokens. Typically the tokens are fixed and the
administrator tries to make the best use of the system access controls
to prevent misuse. In 99% of the cases a smart card is used
interactively from the guy sitting on the PC and currently there is no
way to enforce that.
OK. PolKit may solve some some problems in some cases.

My concern is: what default security policy should be provided by pcsc-lite?
To _not_ break existing system the default configuration should be:
access allowed for any process.
Can we propose something better than that?

Bye
--
Dr. Ludovic Rousseau
Nikos Mavrogiannopoulos
2014-01-06 09:57:08 UTC
Permalink
Post by Ludovic Rousseau
I guess you only have PKCS#15 cards with default (known) transport keys.
Indeed.
Post by Ludovic Rousseau
Post by Nikos Mavrogiannopoulos
Post by Ludovic Rousseau
If you want to avoid a remote user to use a PIN protected card the
best is to use a pinpad reader with a firewall. The PIN will only be
entered using the pinpad. Any PIN verification command will be
rejected by the reader firewall.
Or I can use polkit :) The latter requires no additional hardware and is
already used for access control (to access hard disks) in most systems.
In general administrating a system doesn't always imply selection of the
authenticating tokens. Typically the tokens are fixed and the
administrator tries to make the best use of the system access controls
to prevent misuse. In 99% of the cases a smart card is used
interactively from the guy sitting on the PC and currently there is no
way to enforce that.
OK. PolKit may solve some some problems in some cases.
My concern is: what default security policy should be provided by pcsc-lite?
access allowed for any process.
Can we propose something better than that?
The example file I submitted had as rule, that the console user has full
access, as well as the administrator user. I can modify that to have the
existing pcsc-lite policy of allowing everyone (just change auth_admin
with yes in the policy).

I've also made the polkit support optional (--with-polkit needs to be
explicitly specified), so someone enabling it will be most probably
installing his own policies. I could add some README file that explains
few things with polkit. Let me know for that.

regards,
Nikos
Nikos Mavrogiannopoulos
2014-01-06 10:53:06 UTC
Permalink
Post by Nikos Mavrogiannopoulos
I've also made the polkit support optional (--with-polkit needs to be
explicitly specified), so someone enabling it will be most probably
installing his own policies. I could add some README file that explains
few things with polkit. Let me know for that.
This patch adds documentation (README.polkit) and installs the default
polkit policy to the appropriate location as well as other small
changes.

regards,
Nikos
Ludovic Rousseau
2014-02-11 10:50:24 UTC
Permalink
Post by Nikos Mavrogiannopoulos
Post by Nikos Mavrogiannopoulos
I've also made the polkit support optional (--with-polkit needs to be
explicitly specified), so someone enabling it will be most probably
installing his own policies. I could add some README file that explains
few things with polkit. Let me know for that.
This patch adds documentation (README.polkit) and installs the default
polkit policy to the appropriate location as well as other small
changes.
Committed in revision 6842:
http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2014-February/006397.html

Changes compared to your patch:
- use --enable-polkit instead of --with-polkit
- ./configure will fail instead warn if --enable-polkit is used but
polkit is not found
- some minor changes in the log for src/auth.c
- change the way org.debian.pcsc-lite.policy file is installed

Please check everything is working for you.

Thanks
--
Dr. Ludovic Rousseau
Martin Paljak
2014-02-14 13:16:53 UTC
Permalink
From the auth.c copyright header, that contains a link to
http://www.linuxnet.com/ <- maybe it is time to move on? I don't speak
Japanese to decrypt it but I guess it is not about linux and smart
cards.

I'd say that MUSCLE as a technical term these days is as relevant as
COBOL (which, I'm afraid, is actually used)

Martin
--
Martin
+372 515 6495


On Tue, Feb 11, 2014 at 10:50 AM, Ludovic Rousseau
Post by Nikos Mavrogiannopoulos
Post by Nikos Mavrogiannopoulos
I've also made the polkit support optional (--with-polkit needs to be
explicitly specified), so someone enabling it will be most probably
installing his own policies. I could add some README file that explains
few things with polkit. Let me know for that.
This patch adds documentation (README.polkit) and installs the default
polkit policy to the appropriate location as well as other small
changes.
http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2014-February/006397.html
- use --enable-polkit instead of --with-polkit
- ./configure will fail instead warn if --enable-polkit is used but
polkit is not found
- some minor changes in the log for src/auth.c
- change the way org.debian.pcsc-lite.policy file is installed
Please check everything is working for you.
Thanks
--
Dr. Ludovic Rousseau
_______________________________________________
Muscle mailing list
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Ludovic Rousseau
2014-02-14 15:47:14 UTC
Permalink
From the auth.c copyright header, that contains a link to
http://www.linuxnet.com/ <- maybe it is time to move on? I don't speak
Japanese to decrypt it but I guess it is not about linux and smart
cards.
I'd say that MUSCLE as a technical term these days is as relevant as
COBOL (which, I'm afraid, is actually used)
I fixed the auth.{c,h} files in revision 6850.

In fact all the files contain this wrong URL. I then made a mass-replace.

Thanks for the bug report.

Bye
--
Dr. Ludovic Rousseau
Nikos Mavrogiannopoulos
2014-02-18 16:14:46 UTC
Permalink
Post by Ludovic Rousseau
Post by Nikos Mavrogiannopoulos
Post by Nikos Mavrogiannopoulos
I've also made the polkit support optional (--with-polkit needs to be
explicitly specified), so someone enabling it will be most probably
installing his own policies. I could add some README file that explains
few things with polkit. Let me know for that.
This patch adds documentation (README.polkit) and installs the default
polkit policy to the appropriate location as well as other small
changes.
http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2014-February/006397.html
- use --enable-polkit instead of --with-polkit
- ./configure will fail instead warn if --enable-polkit is used but
polkit is not found
- some minor changes in the log for src/auth.c
- change the way org.debian.pcsc-lite.policy file is installed
Please check everything is working for you.
Thank you, it looks ok.

regards,
Nikos

Nikos Mavrogiannopoulos
2013-12-18 13:56:49 UTC
Permalink
Post by Nikos Mavrogiannopoulos
Hello,
This patch adds polkit [0] support to pcscd, if the --with-polkit
configure option is specified. That allows more fine grained access
control to smart cards (e.g., only console users can access the card
and so on). It is a preliminary patch and the pcscd option with
very crude access control (allowed to access or not). Please let me
know of any comments.
The attached patch provides more fine-grained access control. It splits
the access control to PCSC daemon access, and smart card access. The
latter can even be restricted with a polkit ruleset to specific smart cards.

regards,
Nikos
Ludovic Rousseau
2013-12-21 12:00:41 UTC
Permalink
Hello,
Post by Nikos Mavrogiannopoulos
Post by Nikos Mavrogiannopoulos
Hello,
This patch adds polkit [0] support to pcscd, if the --with-polkit
configure option is specified. That allows more fine grained access
control to smart cards (e.g., only console users can access the card
and so on). It is a preliminary patch and the pcscd option with
very crude access control (allowed to access or not). Please let me
know of any comments.
The attached patch provides more fine-grained access control. It splits
the access control to PCSC daemon access, and smart card access. The
latter can even be restricted with a polkit ruleset to specific smart cards.
Some remarks on the patch:
- maybe you should use "org.debian.alioth.pcsc-lite.foobar" instead of
"org.debian.pcsc-lite.foobar" (with alioth added)
- if the client is not authorized you do not return an error code to
the client. The daemon just closes the communication. This will make
debuging difficult. It would be better to return a specific error to
the client application. But such an error is not (yet) defined by
PC/SC

General remarks:
- do you have a configuration file? Is doc/org.debian.pcsc-lite.policy
the default configuration file?
- where can I find documentation about the configuration file?
- how to restrict the access to only specific applications (or processes)?
So more documentation is needed (at least pointers to existing documentation).

On more fundamental question: PC/SC can be used in a PAM module so
_before_ the user is authenticated. How is it supposed to work with a
policy kit configuration that only allows authenticated users?

Regards,
--
Dr. Ludovic Rousseau
Martin Paljak
2013-12-21 19:21:21 UTC
Permalink
Hello,
Post by Ludovic Rousseau
- maybe you should use "org.debian.alioth.pcsc-lite.foobar" instead of
"org.debian.pcsc-lite.foobar" (with alioth added)
Something I've seen a lot with Java code: package names need to be
unique. One way to accomplish this is to use the inverse of your
domain name (which you "control" thus where you can avoid collisions
in a "free world").

But that's not a requirement, only a "good practice if you can't think
of anything else". The only requirement (to avoid problems) is to not
have collisions in package names. If you think that there will be more
"Debians" where will be "more pcsc-lites", you could need more bits.
But I'm sure there will not be another pcsc-lite, even if there would,
it would have a different name. Thus "org.debian.pcsc-lite" is both
memorable and also enough to avoid collisions.

So my suggestion is to keep it "readable" and "possible to type for
humans". org.sourceforge.projects.bla.users.x.Something. is a
ReallyBadPackageName (or similar).

Note to self and others: don't use DokuWiki as the namespace feature
can make one go taxonomy-crazy.


--
Martin
+372 515 6495
Nikos Mavrogiannopoulos
2013-12-22 14:38:32 UTC
Permalink
Post by Ludovic Rousseau
Post by Nikos Mavrogiannopoulos
The attached patch provides more fine-grained access control. It splits
the access control to PCSC daemon access, and smart card access. The
latter can even be restricted with a polkit ruleset to specific smart cards.
- maybe you should use "org.debian.alioth.pcsc-lite.foobar" instead of
"org.debian.pcsc-lite.foobar" (with alioth added)
Hello,
About the name, I pretty much agree with Martin, and my concern was
whether debian would rename alioth at some point. That's why I didn't
use it. I can add it though if you think it should be there.
Post by Ludovic Rousseau
- if the client is not authorized you do not return an error code to
the client. The daemon just closes the communication. This will make
debuging difficult. It would be better to return a specific error to
the client application. But such an error is not (yet) defined by
PC/SC
I'm not aware of the PC/SC protocol. What would you suggest here? Could
it be a pcsc-lite specific error code?
Post by Ludovic Rousseau
- do you have a configuration file? Is doc/org.debian.pcsc-lite.policy
the default configuration file?
It is a reasonable default. It has to be copied
to /usr/share/polkit-1/actions/
Post by Ludovic Rousseau
- where can I find documentation about the configuration file?
Polkit documentation isn't very verbose. It is documented at:
http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
Post by Ludovic Rousseau
- how to restrict the access to only specific applications (or processes)?
So more documentation is needed (at least pointers to existing documentation).
As I understand that can be done using rules. I could not find out any
documentation for rules, but they are javascript files placed
in /usr/share/polkit-1/rules.d/

The rules for a specific smart card to be accessible by the web server
(run as httpd user) could be:

polkit.addRule(function(action, subject) {
if (action.id == "org.debian.alioth.pcsc-lite.access_card" &&
action._detail_reader == "name of reader" &&
subject.user == "httpd" && subject.local == true) {
return polkit.Result.YES;
}
});

polkit.addRule(function(action, subject) {
if (action.id == "org.debian.alioth.pcsc-lite.access_pcsc" &&
subject.user == "httpd" && subject.local == true) {
return polkit.Result.YES;
}
});
Post by Ludovic Rousseau
On more fundamental question: PC/SC can be used in a PAM module so
_before_ the user is authenticated. How is it supposed to work with a
policy kit configuration that only allows authenticated users?
PAM is executed with root privileges so I don't think that this part
could be affected by polkit (at least not by the default configuration I
included).

regards,
Nikos
Loading...