Ludovic Rousseau wrote:
Checking for $DISPLAY in pcsc-lite is a bad idea:
>
1. PC/SC API has nothing to do with X11
Well, yes and no. Strictly speaking the API has nothing to do with
X however if you look at practical applications of a multi-user
system, using the value of the X display is a very good key to
index into a list of what resources should be available to the
user. I imagine that most multi-user systems are running an X server
per user. For those systems that are using some sort of text-based
login scheme (perhaps some Cold War military site in Uzbekistan
that still has a boatload of Russian-made VT-52's :-) then they
will need to come up with some other scheme to use as a key. I
don't seem to see too many of those folks posting here, however :-).
Also, using the value of $DISPLAY as a key and using PAM in pcscd
to validate the UID<->$DISPLAY binding is non-intrusive in it's
default state, since the access control to readers in pcscd is
based completely on what PAM modules you have in your PAM stack,
and we'll be providing a "null" module that just grants everyone
access as pcscd does today.
2. it is easy for a (remote) user process to set DISPLAY=:0.0
> just before calling SCardEstablishContext() and bypass any
> check on $DISPLAY
However it's not very easy to spoof the kernel's knowledge of the
UID that's on the libpcsclite.so end of the connection. As long as
we can trust the UID that the kernel gives us (and if we can't,
then we might as well hang everything up and go home), then we
can implement whatever other checks we want based on that value.
Spoofing $DISPLAY will just lead the spoofer to no access to any
readers, just as if they were to spoof $DISPLAY and try to fire
up an xterm.
Why don't you want to use the file permissions on /var/run/pcscd.pub
as proposed?
Paul talked a bit about this already. In the Sun Ray case, pcscd
will be using different base directories for all of these files.
We haven't worked out the exact mechanism yet, but it will probably
be something where pcscd takes as a command line argument the path
to the bade directory of where all of it's files should live. That
lets us, at run time, segregate Sun Ray X display instances of pcscd
from instances of pcscd that are controlling system board readers,
etc...
All of this stuff will still work the same way by default, so if
you don't issue these magic command line switches, pcscd will
continue to use whatever was compiled into it for file paths.
Another reason that we can't use the file permissions on /var/run/*
is because in a Solaris Trusted Extensions or Solaris Zones
environment, where every user session is either in one of several
zone or in their own zone, things like filesystem mappings now
become local, so that each zone might have it's own view of a
directory like /var/run that won't be the same view as the /var/run
directory in the global zone.
Tightening up security by using zones, especially for a multi-user
system like a Sun Ray server, requires re-thinking a lot of traditional
UNIXisms.
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?
Paul and I talked about this a bit this afternoon, and he suggested
that we do a putenv("DISPLAY=<whatever>") so that only IFD handlers
that are interested in looking at $DISPLAY need to do a getenv() to
get it - using the putenv()/getenv() scheme means that we don't have
to modify any of the existing API/SPI between pcscd and the IFD
handlers.
We don't think we need to give any IFD handlers the UID of the caller,
since by the time to call to the IFD handler is done by pcscd, the
caller will already have been authenticated via the PAM stack.
What happens if the application says "Hey, I am EUID 0, please give
> me access"?
That would be very bad and whoever wrote code like that should be
looking for a job as a used-car salesman :-)
We depend on the kernel to give us the UID of the caller, and we trust
the kernel.
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
