Andreas Jellinghaus wrote: > adding a few "info.capability" to the fci files is fine with me. > > the other side is: how these are evaluated. > > if I have a machine, where both gui access as well console > login need the smart card reader, then giving exclusive rights > to the one logged in, will break console login?
Sharing the smart card is a job of underlaying software (pam_pkcs11 and smart card daemon). HAL an PolicyKit will help only and only by setting UNIX or ACL file permissions. > I understand the things stanislav want to do, and agree they are > nice. (I used to "play redalert.wav" in 93 in a linux mailbox and got > the attention of the sysadmin quite fast :) ) > > but: unix user and groups don't work to implement this at all. PolicyKit uses ACL. Node will be owned by smartcard daemon and ACL will set permissions to user physically sitting at the desk. > (if you are once logged as gui user and e.g. are included in the > audio group, then all you need to do is copy the shell, make it > setgid audio and you are done - later a login on the ssh where you > don't get the audio group, you can run that setgid shell). > sure, the linux security modules stuff can prevent this scenario... Yes, it is not possible with a classical UNIX permissions model. > my private opinion is, that a server granting access to authenticated > users is the best way This solution was used in SuSE in past. It was called resmgr (library that wraps device accesses allowing to keep source code unchanged). The solution was left in favor of simpler ACL and PolicyKit. But even ACL is not a perfect solution and opens. There is still a long run to get a 100% secure device access OS. User A logs in and turns on recording and leaves. User B opens a new session. User a has no more permission to access audio devices. But as recording was started before permissions were restricted, it continues to work. The only possible solution nowadays is a brutal "fuser -k", very probably killing many of innocent desktop applications (mixer applet accesses sound -> kill the panel). Fix is above the scope of this list and has to be solved on many levels (kernel, user space). It includes denying access on already opened files and the all code around to prevent crashing of user space applications. > - X works fine that way e.g. > and I think a central smart card daemon would be great, as you could > e.g. enter the pin once during login and keep the card in a verified state > so applications can use it without asking the user for the pin all the time. > but we have no such software (and some people don't like the scenario), > so that is only idle talk. For Class 1 authentication you can use one of desktop keyrings (gnome-keyring). Writing a binding should not be very complicated. > suze can implement whatever they want, we can't stop them. > and I think it is real nice of stanislav to contact us on the issue, > and discuss the options they have, and synchronize e.g. which keywords > to put into the hal fci file. I think that level of cooperation is great! Well, I have to do something for customers using cjgeldcarte and similar applications. I seen several irritating changes in HAL keywords in past. That is why I want to think twice before dumb creating of few keywords, that will have to be changed in few months. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
