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
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
