Hello, On Sep 5, 2010, at 9:20 PM, Peter Stuge wrote:
> Ludovic Rousseau wrote: >>> maybe: >>> >>> chown pcscd:smartcard /usr/sbin/pcscd >>> chmod 4750 /usr/sbin/pcscd # rwsr-x--- >> >> You should argument/document the change. > > Really? Even in this forum? > > >> With your change only users in group smartcard will be able to run >> pcscd. I guess that is the intention but you should write it. > > I expected everyone to understand since I believe everyone following > this is very smart, and the intent of a group smartcard was already > discussed earlier to be a means of controlling who can use pcscd. >> I will let such a change to the administrator. It is a >> regression/improvement compared to pcsc-lite as it is now and >> should be decided by the local administrator. > > It can definately be a system policy thing. But I believe such policy > is often inspired by upstream, so had you endorsed the idea then it > might become more widespread. It's not a big deal to me though, and > especially since it is a change from what pcsc-lite does already I > understand if you prefer not to do it. The whole thing is also > distribution specific, some distros which focus on policy stuff might > already be doing what I suggested.. Now the pcscd startup is nicely automagic, the init.d entry can be forgotten/removed, the daemon runs as non-root, the controls to tweak the identity of the pcscd process and to control access to pcscd via standard Unix file permissions also seem to be satisfactory. For me Debian/Ubuntu is the de facto standard for "distribution things". They both include a bunch of groups, used with the standard desktop install default user. Encouraging a rubber stamp security standard is IMHO no good signal for distros. PC/SC is a system service, that is supposed to be available by default [1] (the "database operations" is probably not implemented by pcsc-lite), also on Windows. Thus the default should remain "public access". Yes, administrators can tweak it, but that's for their specific needs. I do not suggest restricting access by requiring another group to be added to the default user. The security issues (and advantages) that stem from the use of (cryptographic) smart cards either don't fit well into "normal" multiuser setups or are irrelevant, because of the hopefully sound cryptography that is implemented between the card and the relying party. [1] http://msdn.microsoft.com/en-us/library/aa379479(VS.85).aspx -- Martin Paljak @martinpaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
