Re: [Muscle] Would like to find ideal err const to return in pcsc-lite
Shawn Willden wrote: On Thursday 26 October 2006 01:07, Michael Bender wrote: $DISPLAY is not used as the sole security key, we used trusted data (the UID of the caller, and, in a Solaris Zones/TX environment, the zone information) and the access control policy, implemented in the Sun Ray PAM module, is pretty simple - if the value of $DISPLAY (which can be spoofed) refers to an X display that the UID of the caller controls, then the caller gets access to the reader. Okay, I'm probably just really dense, but: Is the only purpose of passing the $DISPLAY to disambiguate the case where the user is logged into multiple Sun Rays (DTUs, you call them, IIRC) simultaneously? If so, it might clear up a lot of confusion if you say so. If not, what else is it used for? Not authentication, obviously. $DISPLAY is used for two things - one purpose is as an index into a a port number that libpcsclite.so uses when it wants to talk to an instance of pcscd (so that if the base port of pscsd is, say, 9000, then $DISPLAY=:7.0 would contact it's pcscd instance on 9007) and the second is as an untrusted key that is used by pcscd to determine if the caller can access the particular instance of pcscd. We use PAM to determine that, and in the Sun Ray case, we know which X display value is associated with which UID, and our Sun Ray PAM module can then take the untrusted $DISPLAY that comes from the caller and the trusted UID that comes from the kernel via the peer creds that are available on a socket call, and if the two match, then access is granted. For the non-Sun Ray case, someone will have to write a PAM module that performs similar access control for X displays that they are interested in (X terminals, VNC connections, remote X connections, etc...). The latter PAM work is out of the scope of our project. I've asked here for what other information people think that a PAM stack running in the context of pcscd might like in order to do access control for the non-Sun Ray case, but I haven't heard anything from anyone yet. BTW, none of this work is meant to provide a mechanism for PC/SC-lite to work across a network boundary, i.e. between two machines on the network. All of this is restricted to the local machine only. Getting something to work securely over a network is a much bigger challenge, and as I've said in the past, providing a network pipe for APDUs is probably not a good idea. mike -- [EMAIL PROTECTED] Sun Ray Product Engineering I don't speak for my employer. My opinions are not necessarily those of Sun Microsystems, Inc. or any of its wholly-owned subsidiaries. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Would like to find ideal err const to return in pcsc-lite
Shawn Willden wrote: On Thursday 26 October 2006 01:07, Michael Bender wrote: $DISPLAY is not used as the sole security key, we used trusted data (the UID of the caller, and, in a Solaris Zones/TX environment, the zone information) and the access control policy, implemented in the Sun Ray PAM module, is pretty simple - if the value of $DISPLAY (which can be spoofed) refers to an X display that the UID of the caller controls, then the caller gets access to the reader. Okay, I'm probably just really dense, but: Is the only purpose of passing the $DISPLAY to disambiguate the case where the user is logged into multiple Sun Rays (DTUs, you call them, IIRC) simultaneously? If so, it might clear up a lot of confusion if you say so. If not, what else is it used for? Not authentication, obviously. When built with the option, ./configure --enable-inetv4, the default will be for pcscd to use a base port# with xdpy# added as an offest. libpcsclite.so will use $DISPLAY to know which port to connect to. NOTE: ./configure --enable-well-known-port[=port#] would enable a different port numbering scheme. Server side, pcscd is launched per X session, and is passed it's lifetime unique xdpy# via argv[], to determine which port to listen on (in default port #'ing scheme). However, that doesn't preclude sending ihe client's *intended* xdpy# over the socket (along with the other $DISPLAY components), to provide more info to potentially validate, authenticate and/or use in making data-routing decisions. Mike Bender, an old-timer on this list and in the Sun Ray group can possibly respond to this better or lend important perspective. Paul Shawn. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] 64-bit problem
On Thursday 26 October 2006 11:45, sc wrote: > I called the support on the Windows app I need it for > (and where I got my scr301 to begin with) on Windows and they said it is > pretty specific which reader it needs, as they said "this one or no > one" (either that, or they just didn't want to bother with my question). It is possible that they wrote the app to look for a particular hard-coded reader. I've seen that done a few times. If that's the issue, and you're really ambitious, you might be able to take a hex editor to the binary and hack the reader string to make it look for the reader that you have. It's also possible that another reader will work just fine, but they won't tell you that because they don't want to support it if it doesn't work. If you have another reader, it's worth trying it just to see if it does. Shawn. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Would like to find ideal err const to return in pcsc-lite
On Thursday 26 October 2006 01:07, Michael Bender wrote: > $DISPLAY is not used as the sole security key, we used trusted data > (the UID of the caller, and, in a Solaris Zones/TX environment, the > zone information) and the access control policy, implemented in the > Sun Ray PAM module, is pretty simple - if the value of $DISPLAY (which > can be spoofed) refers to an X display that the UID of the caller > controls, then the caller gets access to the reader. Okay, I'm probably just really dense, but: Is the only purpose of passing the $DISPLAY to disambiguate the case where the user is logged into multiple Sun Rays (DTUs, you call them, IIRC) simultaneously? If so, it might clear up a lot of confusion if you say so. If not, what else is it used for? Not authentication, obviously. Shawn. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Driver for remote card reader
Peter Koch wrote: Hi I don't know if what you want to do is possible. If the reader is already detected and used by Windows you should not have the opportunity to use the _same_ reader with _another_ driver at the same time. Or the reader will only be accessible using your redirection driver, even for a local use? Or no local use will ever be possible? I don't want to write a windows-driver for a real reader, but one that emulates a reader by sending all PC/SC-commands to a daemon that runs on differnet machine. So far I wrote an ifd_handler for pcsclite that send all PC/SC-commands to a daemon running under windows. But my main goal is to do this vice-versa. You may end up redesigning a resource manager like pcsc-lite. Maybe a better approach is to proxy the PC/SC calls from the client to the server. Isn't that what I'm trying to do? The PCSC-client is the ifd_handler and the PCSC-server is the daemon-program. My main problem is how to write the windows-client. Douglas E. Engert wrote: PCSC, (but I don't think it is in PCSC-lite), has the capability to make connections over the network. The Microsoft Remote Desktop Connection knows how share smart card readers along with disks, printers and serial ports I think hte RDC is using PCSC. Useful for smart card login. This sounds interesting. Unfortunately I'm not familiar with RDC. Does that mean that one windows workstation can use the smartcard reader of another workstation via the RDC-protocoll? If yes, how do I do this? On XP PRO the server is enabled by MyComputer->Properties->Remote the click on "Allow users to connect remotely to this computer" On XP PRO the client is under Start->Programs->Accesories->Comunication->Remote Desktop Connection Then run the client and look under Options->Local Resources The last check box should be "smart cards". Remote-Desktop sounds like "One machine is sharing its desktop to another machine". Think of it as ssh to shhd with X windows being tunneled back to the ssh machine. RDC can also share the local printer, local disks, sound and local serial port. Assume machine A has a smartcard reader and machine B has not. I would like to install a driver on machine B that allows applications on machine B to talk to a virtual smartcard reader on B which will forward all commands to the real reader on A. This is done for you by the Microsoft PCSC. In the test I was doing from home to work, I took a GemPC Twin (ccid) home, and connected it to my home XP pro system, started the VPN (required at our site) and got the login panel of my office machine at work. That machine has the OpenSC Smart Card Bundle, and is configured to allow smart card logins using the IdAlly CSP that talks to the OpenSC pkcs11. (The IdAlly is only needed if you want the login or to work with IE. I believe I also tried using the smart card with Mozilla.) You could also use the OpenSC tools to look at what it could see. I don't recall having to install anything i.e. reader drivers on the home machine, as windows had a ccid driver. Now if A shares its desktop with B, the only thing a user at B can do is to start applications on A. No application on B can talk to the reader on A. Or am I confusing things? The reader is on the machine the user is sitting at, in my case the home computer. Although the machine at work, had a smartcard reader, the login session I had from home was not allowed to access it as would be expected. Trying RDC on two XP Pro systems is trival with password login. Give it a try. The Unix rdesktop can be used on the local client side, and can share some devices but not the smart card. The patch posted on another e-mail sounds interesting. Bye Peter -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
RE: [Muscle] 64-bit problem
On Thu, 2006-10-26 at 10:26 -0500, Byron Johnson wrote: > You can request 64-bit drivers from the vendor and they will make available > if possible. I had to request them via email for Windows XP Pro 64. I too am > using a SCR301 with 64-bit SLED 10.0.1. I have yet to request the 64-bit > driver but will do so soon. > Yes, I would have to do that to for FC6 it seems. But then again, for the time being, I will rather just set up FC6 on my notebook which is i368. It seems a lot less hassle. My "any ccid reader" plan will not work as it looks, I called the support on the Windows app I need it for (and where I got my scr301 to begin with) on Windows and they said it is pretty specific which reader it needs, as they said "this one or no one" (either that, or they just didn't want to bother with my question). thanks to both of you for information m. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ludovic Rousseau > Sent: Thursday, October 26, 2006 9:49 AM > To: MUSCLE > Subject: Re: [Muscle] 64-bit problem > > On 26/10/06, sc <[EMAIL PROTECTED]> wrote: > > I own scm-301 and so I downloaded > > http://www.linuxnet.com/drivers/readers/files/scm310Driver-0.9.0.tar.gz > > and as it seems it only provides i386 AdmHndlr.o, no 64-bit. > > Yes. It is a bad idea to use proprietary drivers. > > > Otherwise, (since I only have one reader and I'm more or less guessing > > on this topic, read as... clueless as it gets) does any usb card reader > > works out of the box with ccid only (the i386 object seems present in > > all drivers I looked into)? > > > > Well,... it might be even the fact I would just understand it wrong and > > no 64-bit drivers for cards exist. As I said it was the first try to get > > card working under linux, so any help is appreciated. > > You can use any reader listed on [1] in the "Supported CCID readers" > list and use it with the driver available on the same page. > > Other drivers are also working fine on 64-bits systems maybe but not > with the SCM 301 you have. I am afraid you will have to buy a new > reader. > > Bye > > [1] http://pcsclite.alioth.debian.org/ccid.html > ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Driver for remote card reader
Peter Koch wrote on 10/26/06 09:10 AM: Douglas E. Engert wrote: PCSC, (but I don't think it is in PCSC-lite), has the capability to make connections over the network. The Microsoft Remote Desktop Connection knows how share smart card readers along with disks, printers and serial ports I think hte RDC is using PCSC. Useful for smart card login. This sounds interesting. Unfortunately I'm not familiar with RDC. Does that mean that one windows workstation can use the smartcard reader of another workstation via the RDC-protocoll? If yes, how do I do this? Remote-Desktop sounds like "One machine is sharing its desktop to another machine". Assume machine A has a smartcard reader and machine B has not. I would like to install a driver on machine B that allows applications on machine B to talk to a virtual smartcard reader on B which will forward all commands to the real reader on A. Now if A shares its desktop with B, the only thing a user at B can do is to start applications on A. No application on B can talk to the reader on A. Or am I confusing things? I think so. RDC allows you to remotely access a desktop session that's running on B, while you're sitting at A. A will be running its own desktop session, and the desktop from B will be displayed inside a window, or it could be made to occupy the full screen. There typically wouldn't be a user sitting at B will this is happening. If B is a running a personal version of Windows, like XP, it'll only allow one desktop session to be accessed from one place at a time - when the remote connection is made, the desktop session will be detached from the local console (it'll go back to showing a login screen). If B is running a server-class OS like Windows 2003, with Terminal Services, it can support many simultaneous remote desktop sessions, all accessed from different clients. ~Iain ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Driver for remote card reader
Hi > I don't know if what you want to do is possible. If the reader is > already detected and used by Windows you should not have the > opportunity to use the _same_ reader with _another_ driver at the same > time. Or the reader will only be accessible using your redirection > driver, even for a local use? Or no local use will ever be possible? I don't want to write a windows-driver for a real reader, but one that emulates a reader by sending all PC/SC-commands to a daemon that runs on differnet machine. So far I wrote an ifd_handler for pcsclite that send all PC/SC-commands to a daemon running under windows. But my main goal is to do this vice-versa. > You may end up redesigning a resource manager like pcsc-lite. Maybe a > better approach is to proxy the PC/SC calls from the client to the > server. Isn't that what I'm trying to do? The PCSC-client is the ifd_handler and the PCSC-server is the daemon-program. My main problem is how to write the windows-client. Douglas E. Engert wrote: > PCSC, (but I don't think it is in PCSC-lite), has the capability > to make connections over the network. The Microsoft Remote Desktop > Connection knows how share smart card readers along with disks, > printers and serial ports I think hte RDC is using PCSC. Useful for > smart card login. This sounds interesting. Unfortunately I'm not familiar with RDC. Does that mean that one windows workstation can use the smartcard reader of another workstation via the RDC-protocoll? If yes, how do I do this? Remote-Desktop sounds like "One machine is sharing its desktop to another machine". Assume machine A has a smartcard reader and machine B has not. I would like to install a driver on machine B that allows applications on machine B to talk to a virtual smartcard reader on B which will forward all commands to the real reader on A. Now if A shares its desktop with B, the only thing a user at B can do is to start applications on A. No application on B can talk to the reader on A. Or am I confusing things? Bye Peter -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Would like to find ideal err const to return in pcsc-lite
On Wed, 25 Oct 2006, Michael Bender wrote: Jesse I Pollard - CONTRACTOR wrote: Michael Bender wrote: Sure, but the user/administrator need to fix whatever configuration is allowing something like ssh to grab :0 - I don't think that this is a common use case. You can't prevent it. If port 6000 is not being used, then any user application may allocate it. On Solaris at least, you can mark any port as a privileged port (both UDP and TCP). Not sure about Linux. I guess that the issue with 6000 really depends on if the console X server (that would be the normal X server that uses 6000) starts up before someone can log in and grab 6000 (by any means). I'm not sure if there is some code somewhere that sets 6000 as a privileged port or not. Anyway, what does this have to do with pcscd? Nothing. It has to do with telling pcsd to grant access to the smartcard reader by using the disply number as part of the key. Since (in my opinion) the key is vulnerable to spoofing, the decision to grant access is also vulnerable. This could give the process doing the spoofing remote access to a smartcard without the users authorization. Such connections can then be used to generate derived certificates for unauthorized use elsewhere. There is also the issue of when the X server strictly uses the named socket in /tmp/.X11-unix/X0 and doesn't use socket 6000. How does the issue of which socket the X server uses affect this discussion concerning pcscd? It defines the display number used as part of the access key. It determines what the X display environment value is. If port 6000 isn't being used, then it becomes :0. If it is being used, then :1 is used. This is an X server thing. I still don't see what this has to do with pcscd. Again, only in that the display number is used as part of the checks to control access to the smartcard. XDM has some minimal configuration that assignes the X display and X server. If port 6000 is used, then it will not start an X server. Well sort of - the X server starts, but cannot open it's designated socket, so it then terminates, XDM then reports a falure to syslog. OK. What does XDM have to do with pcscd? You are assuming the user generating the :0 display would be given that privilege in the first place. He may be attacking the system via the smartcard reader. How is that possible? There is a race condition between XDM and the X server startup. During initial login, the X server MUST be local to allow the user to enter PIN/other security related information. Then XDM aborts the display and starts a new X server with the credentials of the authorized user. XDM does not control port 6000, which defines the X display number (port 6000 is used for display 0:0, 6001 for display 1:0...). This window is only open a short time (depends on the overall system speed) somewhere around 1 second or less. If, during this window, an external attack is carried out via the users base credentials, then the X display being assumed for access checks will NOT be those of a local X server, but a proxy. I have written such a proxy myself (which is why I'm familar with the mechanics). It only takes a about 1000 lines of code to make a proxy. This is no inherently a problem - It only becomes a problem when you assume the X display really is on the console. OK, but what does this have to do with pcscd? Again, only in that the display number is used as part of the checks to control access to the smartcard. I was told that the validation checks to ensure that the display specified is in control of the same credentials as the X display. This is made under the assumption that both the smartcard reader and display are local. This is the assumption I am challenging by trying to present how an attack could be accomplished by having a "local" display that is a spoofed/proxy X server. Can it be blocked? Sure - but it requires the pcscd dameon/card reader session to be reset, forcing the user to input his PIN twice for a login. The first time to authenticate the local user (via the PAM module), a second time to gain usable access during the login. This is an awkward procedure, and I am reasonably sure is not being done. Is it still "safe"? I'm not sure. Even doing this, there may be other potential vulerabilities (not sure, this is speculative, and I have no immediate evidence) there MAY be a way to insert a man-in-the-middle attack by coercing the application to open a different socket (to the attacker) which then forwards the connection to the local pcscd server. This would grant full access to the smartcard reader (and PIN exposure) to the attacker. I do think this vulnerability to be most difficult to implement... In the past, I have been able to capture PIN entry while I was debugging/analyzing local implementation problems. There are still a LOT of things I don't yet know about how everything works. And the documentation available seems to assume some "things" (
RE: [Muscle] 64-bit problem
You can request 64-bit drivers from the vendor and they will make available if possible. I had to request them via email for Windows XP Pro 64. I too am using a SCR301 with 64-bit SLED 10.0.1. I have yet to request the 64-bit driver but will do so soon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ludovic Rousseau Sent: Thursday, October 26, 2006 9:49 AM To: MUSCLE Subject: Re: [Muscle] 64-bit problem On 26/10/06, sc <[EMAIL PROTECTED]> wrote: > I own scm-301 and so I downloaded > http://www.linuxnet.com/drivers/readers/files/scm310Driver-0.9.0.tar.gz > and as it seems it only provides i386 AdmHndlr.o, no 64-bit. Yes. It is a bad idea to use proprietary drivers. > Otherwise, (since I only have one reader and I'm more or less guessing > on this topic, read as... clueless as it gets) does any usb card reader > works out of the box with ccid only (the i386 object seems present in > all drivers I looked into)? > > Well,... it might be even the fact I would just understand it wrong and > no 64-bit drivers for cards exist. As I said it was the first try to get > card working under linux, so any help is appreciated. You can use any reader listed on [1] in the "Supported CCID readers" list and use it with the driver available on the same page. Other drivers are also working fine on 64-bits systems maybe but not with the SCM 301 you have. I am afraid you will have to buy a new reader. Bye [1] http://pcsclite.alioth.debian.org/ccid.html -- Dr. Ludovic Rousseau ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] 64-bit problem
On 26/10/06, sc <[EMAIL PROTECTED]> wrote: I own scm-301 and so I downloaded http://www.linuxnet.com/drivers/readers/files/scm310Driver-0.9.0.tar.gz and as it seems it only provides i386 AdmHndlr.o, no 64-bit. Yes. It is a bad idea to use proprietary drivers. Otherwise, (since I only have one reader and I'm more or less guessing on this topic, read as... clueless as it gets) does any usb card reader works out of the box with ccid only (the i386 object seems present in all drivers I looked into)? Well,... it might be even the fact I would just understand it wrong and no 64-bit drivers for cards exist. As I said it was the first try to get card working under linux, so any help is appreciated. You can use any reader listed on [1] in the "Supported CCID readers" list and use it with the driver available on the same page. Other drivers are also working fine on 64-bits systems maybe but not with the SCM 301 you have. I am afraid you will have to buy a new reader. Bye [1] http://pcsclite.alioth.debian.org/ccid.html -- Dr. Ludovic Rousseau ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
[Muscle] 64-bit problem
I own scm-301 and so I downloaded http://www.linuxnet.com/drivers/readers/files/scm310Driver-0.9.0.tar.gz and as it seems it only provides i386 AdmHndlr.o, no 64-bit. # objdump -f backup/AdmHndlr.o AdmHndlr.o: file format elf32-i386 architecture: i386, flags 0x0011: HAS_RELOC, HAS_SYMS start address 0x Since source for AdmHndlr.c is not included, I guess it contains some proprietary data, which I don't mind the slightest. But,... could you please include 64-bit object too, otherwise linker fails? Otherwise, (since I only have one reader and I'm more or less guessing on this topic, read as... clueless as it gets) does any usb card reader works out of the box with ccid only (the i386 object seems present in all drivers I looked into)? Well,... it might be even the fact I would just understand it wrong and no 64-bit drivers for cards exist. As I said it was the first try to get card working under linux, so any help is appreciated. thanks m. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Jesse I Pollard - CONTRACTOR wrote:
On Fri, 20 Oct 2006, Paul Klissner wrote:
Here's a link to an improved diagram:
http://www.freemyimage.com/ims/pic.php?u=1500BLfhm&i=15663
That helps. And the diagram does omit how the xdpy# is generated to
even be available to ifd handler. This is the only weakness I see.
xdpy# comes from the caller of libpcsclite.so. Whatever the results
of a getenv("DISPLAY") are gets parsed in the library and the parsed
results are sent to the appropriate pscsd instance (after some sanity
checking in the library).
The ifd and pcscd cannot determin if the Xdpy# value is beeing spoofed.
The ifd trusts that the Xdpy# sent from pcscd has been authenticated.
The ifd does not need to make access control decisions. pcscd does
that.
pcscd does that via PAM. PAM does that via specific PAM modules. We
are writing one for Sun Ray. We are also writing one for the default
case of no access restrictions so that the default behavior of pcscd
is the same as it is today (i.e. everyone gets access to all the
readers).
The X server, XDM, ssh, and peanut butter sandwiches are in no way
involved in any of this.
You do show where the zone label comes from (socket credentials from
the kernel) But you cannot get the Xdpy# that way.
Yes, that is absolutely correct. We can not get the Xdpy# from
socket credentials.
Another question (though not really a security one) - what happens
> when one user has two Sun Ray displays at a desk?
Sun Ray uses the username as one of the keys in identifying a
Sun Ray session (it also uses other mechanisms as well). What
that means is that the same username can only have one Sun Ray
session associated with that username on a Sun Ray server at
one time, i.e. the user "joesmith" can't have more than one
Sun Ray session associated with his username. Sun Ray has a
mode that associates either the MAC address of the DTU or a
token ID read from a smartcard (note that this is *not* using
authenticated smartcard access, this is simply using a token
read from the card to associate with a session) and in those
two cases, multiple sessions can be logged in with the same
UNIX username, although to the Sun Ray server, they are each
separate, unique sessions.
I can see this happening more on a developers desk instead of a normal
users desk - Both systems may need the smartcard simultaneously. There
is also the possibility of cross matched zones (both belong to the user,
both X servers belong to the same user, and for some reason, the user
chooses to send a X window to the other display...)
Whatever the value of $DISPLAY is at the time that SCardEstablishContext
is called will be used to connect to the appropriate pcscd instance.
If the UID of the caller is allowed to access that X display, then
they also get access to the reader. The same way that it works when
you fire up an xterm.
Btw, The diagram does leave out one other piece of info:
I assume each box at the bottom represents a SunRay display/system, and
the single box on top is the remote server system.
The box labeled "Sun Ray DTU" represents the Sun Ray thin client, the
thing that sits on your desk and to which you attach a display, keyboard
and mouse, and which has an internal smartcard reader.
The boxes labeled "xxx zone" refer to instances of local zones that
Sun Ray sessions run in. Other than the DTU, all of the rest of this
stuff lives on the Sun Ray server, a box running Solaris or Linux.
The diagram also only illustrates the static result of all decisions made,
and almost non none of the steps to get that way. I think those steps
and the security decisions required to procede from state to state are
needed to fill out the security table of data source/allowed
state/destination state. I think that would show that the Xdpy# is
an uncontroled datum being used for security decisions.
So are we now doing a full security review for FIPS certification
here on the MUSCLE list such that all documentation, including
diagrams, must be provided down to the last detail?
mike
--
[EMAIL PROTECTED] Sun Ray Product Engineering
I don't speak for my employer. My opinions are not necessarily those of
Sun Microsystems, Inc. or any of its wholly-owned subsidiaries.
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Ludovic Rousseau wrote: On 26/10/06, Michael Bender <[EMAIL PROTECTED]> wrote: >> Do you need to have different drivers for different zones >> or DTUs? Yes, we want to be able to give each instance of pcscd its own set of ifd handlers, so that, for example, if an instance of pcscd is running in a Sun Ray session, it will only know about the Sun Ray ifd handler for the internal reader in the Sun Ray DTU, while if an instance of pcscd is running for the console user, it will only know about the ccid USB ifd handler and the ifd handler for the console's internal reader. What would be the problem if a pcscd in a Sun Ray session also has access to a driver for a CCID reader? Nothing at all from a technical perspective. Some customers would want to prevent the pcscd instance running in a Sun Ray session from even being able to load the ccid (or any other) ifd handler. It would not use it (not even load it in memory) unless a CCID driver is connected to the Sun Ray. pcscd would just read the Info.plist of the driver. Unless you modified pcscd on this point. That was just an example. We actually would want both the Sun Ray DTU ifd handler and the ccid ifd handler to be available by default for a Sun Ray session. We might not want, say, an ifd handler for the system box reader to be available for a Sun Ray session. Is it possible to use the Sun Ray internal reader for session mobility and also connect an external smart card reader (say a CCID one) to use a smart card application like a PKCS#11 in Mozilla? Yes. mike -- [EMAIL PROTECTED] Sun Ray Product Engineering I don't speak for my employer. My opinions are not necessarily those of Sun Microsystems, Inc. or any of its wholly-owned subsidiaries. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Ludovic Rousseau wrote: On 26/10/06, Michael Bender <[EMAIL PROTECTED]> wrote: Ludovic Rousseau wrote: > Note that you can use IFDHGetCapabilities(..., > SCARD_ATTR_VENDOR_IFD_TYPE, ...) (or another similar tag) to check > that the IFD will understand the IFDHcontrol() request. What happens if you send an IFD an IFDHcontrol() request that it doesn't understand? Is it supposed to fail gracefully, or do IFDs tend to just start scribbling on random memory and then cause pcscd to dump core ;-)? The driver should return IFD_COMMUNICATION_ERROR as documented in [1] but it may also do anything else. I imagine you have the driver source code to correct any "deviant" behavior? Well, yes, I suppose that it was more of a rhetorical question. mike -- [EMAIL PROTECTED] Sun Ray Product Engineering I don't speak for my employer. My opinions are not necessarily those of Sun Microsystems, Inc. or any of its wholly-owned subsidiaries. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Jesse I Pollard - CONTRACTOR wrote: It can still be a spoof. The account may have been penetrated externally by a trojan, The user at the console ends up loosing the display because > his account has been taken over by some external means... Don't forget this one: The user might have shoved a peanut butter sandwich into the DVD-ROM slot and thus no one is able to use a DVD-ROM to update the system software anymore. This whole discussion is getting ridiculous. We are working on making PC/SC-lite work properly in a multi-user environment, not trying to fix every conceivable security hole that UNIX has ever had or that it may ever develop. mike -- [EMAIL PROTECTED] Sun Ray Product Engineering I don't speak for my employer. My opinions are not necessarily those of Sun Microsystems, Inc. or any of its wholly-owned subsidiaries. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Would like to find ideal err const to return in pcsc-lite
Jesse I Pollard - CONTRACTOR wrote: Michael Bender wrote: That scheme introduces another layer of administration and configuration - Kerberos - that requires the site to deploy Kerberos. We don't want to enforce any requirement like that, since requiring Kerberos or PKI certs or any of the higher-level authentication mechanisms that are cool in theory actually break down in practice since you can't assume that a site is going to setup a Kerberos infrastructure or a CA just so that they can transfer a few APDUs between their browser and a smartcard reader. No - only the solution is similar. No need for Kerberos to implement the METHOD of inheritance. All changes would be done in the library using/starting the pscd daemon. Huh? So are you saying that the *library* is now responsible for starting the pcscd daemon? > This is the only change needed Cool, then please describe this simple change that will make the existing pcscd/libpcsclite.so work properly on a Sun Ray server running under Solaris 10 with Trusted Extension enabled. One of the big reasons that we're not all using smartcards for login and cryptography today is because all of the required infrastructure is just such a big PITA to set up. At Sun, for example, we have been working on a smartcard-based employee badging system for physical facility access and logical access to our internal networks, and it is a hard problem to move from the single user on the desktop using a free cert from Thawte to demo to the VP to actually rolling out certs for 40,000 people, handling certificate issuance and revocation, modifying all applications to use something other than username/password (and getting the damned window systems to do proper PAM conversation functions!) and all the rest. piffle. The real problem is that the smartcards cannot provide distributed authentication. piffle to you. Sure they can with help from the proper infrastructure such as an identity manager, Kerberos deployment or other back-end help. That and the lack of source code for accessing the reader. OK, that's a new one to me. What source code do you think is lacking? Is there some piece of the MUSCLE project that isn't available in source? Is there some Linux code that is not available in source that prevents using smartcards in an enterprise for authentication? > So far, all implementations use something else. OK, what else do they use? Both windows and UNIX based systems currently are using/planning on using the Kerberos foundation. I don't think that's accurate. I think that the best that anyone can say is that Windows and UNIX systems provide the ability to enable the use of Kerberos, but whether or not Kerberos or any other distributed authentication mechanism is used depends on the system administrator and the site security policy. > We at NRL solved a similar problem with Kerberos (lack of keyrings) > by having the X server create a server process and a UNIX domain > socket that is received by every child process. We can't use UNIX domain sockets to cross the local<->global zone boundary. A local zone really does look a like like it's own virtual machine[1] and so a lot of the traditional mechanisms that UNIX code uses today to do client<->daemon communication don't work across zone boundaries. The only environment variable that we're using is $DISPLAY, and that will serve as the index that the transport mechanism will use to allow libpcsclite.so and pcscd to communicate. It might be that we use $DISPLAY added to some base port number value to determine which port number to use (as X does) - we're still working on that part of the transport scheme. Whatever we do, we'll keep it simple and keep the default to be that PC/SC-lite works the same way as it does today so that we don't cause regressions. Unfortunately, the user controls that piece of data. And that makes it untrustworthy for a security key. $DISPLAY is not used as the sole security key, we used trusted data (the UID of the caller, and, in a Solaris Zones/TX environment, the zone information) and the access control policy, implemented in the Sun Ray PAM module, is pretty simple - if the value of $DISPLAY (which can be spoofed) refers to an X display that the UID of the caller controls, then the caller gets access to the reader. The UID can not be spoofed (without hacking the kernel and socket interfaces). That is for *Sun Ray*, as I've said all along, since the access control is done via PAM, anyone can do whatever other checks they want to do in a non-Sun Ray environment by writing the appropriate PAM module. If you want to user Kerberos for the console user, then by all means, write a PAM module that can check the ticket for the caller. What other data do you need a PAM module to see in order to do this other than UID (trusted), pid (trusted) and $DISPLAY (untrusted) of the caller? What is your concern with this approach? The work that Paul and I are doing doesn't mandate any security/
