Re: [opensc-devel] Announcing debugging server and asking for advice
Jean-Michel Pouré - GOOZE wrote: > > You can modify sshd a little or use some PAM module which I'm sure > > can implement this policy. > > > > For sshd you can start by setting MaxSessions to 1, but there's no > > MaxAuthenticatedSessions setting. Be careful with MaxStartups, or > > it becomes very easy to deny service. > > Thanks, I will try this way. Note that MaxSessions doesn't do what you want, so if you don't want to get into the sshd code then you have to configure some PAM thing. Doing it in sshd will probably be faster though. //Peter pgpgTrzvg0Fv2.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Announcing debugging server and asking for advice
Le mardi 29 mai 2012 à 13:49 +0200, Peter Stuge a écrit : > > You can modify sshd a little or use some PAM module which I'm sure > can implement this policy. > > For sshd you can start by setting MaxSessions to 1, but there's no > MaxAuthenticatedSessions setting. Be careful with MaxStartups, or > it becomes very easy to deny service. Thanks, I will try this way. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Announcing debugging server and asking for advice
Jean-Michel Pouré - GOOZE wrote: > * If possible, I would like to restrict the number of concurrent > sessions in OpenSSH an set it to one. There should be no idle session. > If someone is already connected doing debugging, OpenSSH should reject > connection. This is the most tricky part of the settings as I have NO > IDEA how to achieve this. You can modify sshd a little or use some PAM module which I'm sure can implement this policy. For sshd you can start by setting MaxSessions to 1, but there's no MaxAuthenticatedSessions setting. Be careful with MaxStartups, or it becomes very easy to deny service. //Peter pgp61BsKzbAG3.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Docs/Specs on ACLs / security attributes?
Hi Peter I have just implemented a thing related to ACL for OpenPGP. Is it similar to what you want? https://github.com/hongquan/OpenSC-OpenPGP/commit/5a3fb311409fe71b82336ec29b586ae713a7b9e8 On 05/28/2012 09:31 PM, Peter Marschall wrote: > Hi, > > On Monday, 28. May 2012, Martin Paljak wrote: >> I don't really understand how you would use ACL-s with the "gender" >> field, for example. > Let me try to explain what I want to achieve. > > card-openpgp.c emulates a filesystem for the DOs on the card. > > Now, some of the DOs are > * readable after VERIFY PIN2 > some are > * writeable a VERIFY PIN2 > some are > * writeable after VERIFY PIN3 > ... > (and the sets may overlap) > > All this information is written in the spec only, and thus is implicit. > (i.e. the DO do not tell about their permissions) > > This "implicit only" behaviour does not necessarily extend to the > emulated file system. > (i.e. the emulated files can have emulated ACLs, ... that can be > evaluated by tools) > > My goal is to extend openpgp-tool in a way that it does not need > implicit information on the readability/writeablity of the DOs, but > can use standard-compliant data to get the information. > This way the mapping only needs to be done in card-openpgp.c only > instead of distributed over many places. > > Let me try to show it graphically > > On the Card > DO 0101 > permissions (implicit from the spec) > read: always > write: VERIFY PIN2 > | > | (this happens in card-openpgp.c) > | > v > Emulated File System > EF 0101 > ACL: READ=always, WRITE=VERIFY CHV2 > > Currently the ACLs are not emulated yet. > But If they are, then standard-compliant applications can determine > what needs to be done in order to be able to e.g. write to an emulated EF. > > So, the ACLs shall not in any way try to influnce what happens on the card (I > am very crealy aware that they can't), but tell to the outside world how the > permissions are laid out on an OpenPGP card. > This way not every application needs to know the specs of an OpenPGP > card, but can use the information provided by the emulation. > > I hope that makes my goals clearer. > > If this is not doable with either security attributes or/and ACLs, because > their intention and potential use cases conflict with that goal, please tell. > > Best regards > Peter > -- Regards, Quân ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Announcing debugging server and asking for advice
Dear all, As part of the preparation work to reorganize and give more power to the community at large, we are happy to announce that we are setting up a debugging server for OpenSC. This is not the QA farm, as QA an automated testing tool. The aim of the debugging server is to give OpenSC main developers access to the most popular smarcards in a debugging environment. Some smartcards are hard to find or come in a developer version, for example the Starcos SPK 2.3. Others are quite expensive, I wron't comment. So IMHO it is better to do testing on a shared server. So we plan to implement the following, advice is welcome: * pcscd should be started in user mode and debug mode with output to log file, upon user connection. Users are part of pcscd group, so they should be able to access smartcards, kill and restart the daemon. * If possible, I would like to restrict the number of concurrent sessions in OpenSSH an set it to one. There should be no idle session. If someone is already connected doing debugging, OpenSSH should reject connection. This is the most tricky part of the settings as I have NO IDEA how to achieve this. * What debugging/profiling tools do you need? gbd, what else? * Anyone can ask for access, just write me jmpo...@gooze.eu. Access is free as in free beer. As usual, donations of smartcards are welcome. We now need two cards from the same vendor/type: one card for the QA farm, another for the debugging server. The first version of the debugging server will be online on Wednesday, comments are welcome. Let the force be with us! Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
