Shawn,
On Thursday 19 October 2006 17:54, Michael Bender wrote:
There might be other credentials that would be important in making
this decision and which could be passed up from libpcsclite.so, got
any suggestions as to what else might be interesting? Or perhaps
we could make it more opaque in the sense that we pass a "blob" of
stuff from the client side, through pcscd, and then into the PAM
stack, and only the PAM modules would understand that "blob",
which might be something like key-value pairs. That's for the
future at any rate, for now, we're doing our prototype with just
the value of $DISPLAY and the UID of the caller.
What prevents the application from lying when it provides the name/value
pairs, or the $DISPLAY value? I'm sure it's possible for pcscd to check the
UID under which the client app is executing (because I implemented such a
check for Linux), but it seems like pcscd must simply trust the application
to deliver correct values for the rest.
In the Sun Ray scheme that we are using, there is only one piece of
information that we trust, and that is the UID of the caller. We trust
that since we get it from the kernel (via the peer cred struct, or
if using in-kernel RPC or doors, via mechanisms that those transports
provide). The caller can give us any $DISPLAY value that they want,
but since Sun Ray maintains a mapping of UID to $DISPLAY, then only
the values of $DISPLAY that Sun Ray knows are associated with the
passed UID will be allowed to complete the transaction (via the call
to PAM).
So, if you're logged into a Sun Ray as user "swilden" and your UID
is 1234 and your $DISPLAY is :37, then your smartcard application
will only get access to the readers that the instance of pcscd that
has been started for the X server handling display :37 controls. If
you try to game the system and set your $DISPLAY to :38 and then
make a libpcsclite.so call, the Sun Ray PAM module in pcscd will
determine that UID 1234 is not allowed to access any resources from
X display :38 and fail the call. This magic occurs since Sun Ray
has this database that keeps track of things like this. Ideally, X
should have implemented a "which UID are you running under now?"
call, but I don't think that there is a generic way to get that
information out of the X server.
Note that in the Sun Ray scheme at least, nothing that your session
does with xauth affects the UID<->Xserver mapping, so we don't grant
other users or other systems access to the reader on :37 just because
you may have done an "xhost +". However, because we are using PAM, if
that was an important feature to have, then someone could write a PAM
module that implemented those authentication semantics as well.
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
