Ludovic Rousseau wrote:
On 19/10/06, Paul Klissner <[EMAIL PROTECTED]> wrote:
Ludovic Rousseau wrote:
> It is easy on the libpcsclite side to check the file permissions of
> /var/run/pcscd.pub and return SCARD_E_NO_PERMISSION when appropriate.
You're right. That error code solves more problems. It doesn't address
things like a bad $DISPLAY environment variable format or bad syntax
directly, but those could be indicated by SCARD_E_INVALID_PARAMETER,
which already exists in pcsclite.h, if the docs indicated clearly
that if $DISPLAY is defined, it becomes an indirect parameter.
Checking for $DISPLAY in pcsc-lite is a bad idea:
1. PC/SC API has nothing to do with X11
Michael Bender explained our architecture in a recent e-mail,
which should convey why we believe a good case is to be made
for it.
2. it is easy for a (remote) user process to set DISPLAY=:0.0 just
before calling SCardEstablishContext() and bypass any check on
$DISPLAY
In the proposed scheme, client-side SCardEstablishContext()
retrieves $DISPLAY, parses it, rejecting bad syntax. It also rejects
any non-local host references in the X Display (locality can
be verified by calling bind on the resolved IP address.
In your example, :0.0 has specified no host, and therefore the
localhost is assumed to be the target.
After doing those preliminary checks, the client passes the X Display
info to the server, where the server retrieves the client's EUID from
the transport mechanism (to thwart UID spoofing by the client),
and passes both EUID and Xdpy# into PAM. PAM authenticates that the
validated EUID is the true owner of the display. That establishes
conclusively that the client has permission to access the card reader
associated with that Xdpy. I am not aware of a vulnerability in this
scheme.
Why don't you want to use the file permissions on /var/run/pcscd.pub
as proposed?
That won't work in our case. We need to modify the /var/run scheme
to handle multiple (many) pcscd daemons running simultaneously. There
are various reasons we want to do that, including, if one pcscd daemon
crashes, it doesn't bring down all the smartcard readers in thie whole
Sun Ray environment.
Mike elaborated on the overall scheme in an e-mail from a couple of
hours ago. I will provide a diagram soon.
But that question does bring me to another question: I need to find a
good way to pass EUID and Xdpy# to our IFD Handler, in a way that plays
nicely with existing IFD handlers.
Which part will send the EUID and Xdpy# to the IFD handler? The user
application?
What happens if the application says "Hey, I am EUID 0, please give me
access"?
We actually only need to convey the Xdpy# to the IFD handler. EUID
doesn't need to be propagated (as I alluded too hastily in my previous
e-mail), since it's purpose is outlived beyond authenticating that
the Xdpy# conveyed IFD handler is owned by the client.
The believe now is we can pass the Xdpy# to the IFD handler safely
using putenv via a single environment variable, since there is a
single pcscd per Sun Ray session/X server.
Thus, for any given pcscd daemon, there will only be one
releveant Xdpy# that needs to be communicated to the IFD handler.
Paul
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
