-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
On Thu, 19 Oct 2006, Michael Bender wrote:
Jesse I Pollard wrote:
Michael Bender wrote:
I'd like to add SCARD_E_INVALID_DISPLAY to the list of err consts
in PCSC/pcsclite.h [...]
Are the list of error/status return codes controlled by the PC/SC
specification itself, so that we are not really at liberty to add
or change codes as we like, or is there not such a tight binding
between what PC/SC-lite and the PC/SC specification for the client
side API (via libpcsclite.so) provides?
I'm thinking of this specific case where we introduce a new error
code, but no applications know about it, so no one uses it, so that
in effect it doesn't provide any additional value?
Hmmm... and how would you determine if the display is invalid?
We're adding PAM support to pcscd so that we don't have to solve
the general problem of figuring out if the caller of libpcsclite.so
is authorized to use a particular X display. The criteria that we're
using for our work now is that the value of $DISPLAY from the
environment and the UID of the caller on the library-end of the
socket (or door, or whatever) get handed to a PAM stack and the
modules there are responsible for determining if the passed UID
is allowed to access resources associated with the passed X display.
How that gets determined is specific to the PAM modules and the
X display (or range of X displays). In the case that we are working
on, we are providing a PAM module that knows how to do this for
Sun Ray (Sun's thin client [1]) X displays using Sun Ray-private
interfaces. We're also going to provide a sample PAM module that
gives pcscd the same reader access semantics and access control
as it has today, namely, none :-) so that we don't introduce a
regression.
Seems rather special purpose and self limited. but ok.
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.
The other bit of information that may not be clear yet is that we
are starting an instance of pcscd for each X display (i.e. for
each X server) on the system. For Sun Ray, that works perfectly
since we never want a Sun Ray session to have access to any readers
other than the ones that are internal to the unit or connected
via USB to the unit. A Sun Ray session will not get access to
readers connected to the system board, or via some kind of network
attached device, etc... That may not be a model that works for
every environment, however. The code to start up a pcscd instance
for each X display is part of the Sun Ray codebase and won't be
put back to open source, however the compile and runtime hooks in
pcscd and libpcsclite.so will be there and given back to the
community.
Having one for each server would work where only one server exists.
With multiple servers on a system you loose the socket identification.
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 recieved by every child process. Any desire to connect to the
users Kerberos cache is achieved by requesting a file id via
a message on the inherited socket. All actual data transfers are done
via the recieved file id (connected to one end of a socketpair).
Identification is automatic - all children of the X server recieve
that socket.
Termination of the server side of the request socket terminates access to
the Kerberos cache. The cache itself is implemented as a memory only
cache, so it automatically cleans up when the server process terminates.
Since logout terminates the xdm process (which serves as the cache server)
it can also terminate acces to the cache. Currently we don't do this to
allow for background processes to continue running; but for the smartcard
reader you would want the process terminated.
Granted, this WOULD alter how applications access the pcsd server... but
only by changing the library function that initiates the connection. The
library function would have to use the domain socket to request a fileid
that has been opened to the pcscd server.
In the Kerberos case, we use the already existing environemnt variable
KRB5CCNAME to have the value "PIPE:1023" where 1023 is the file id to
use for making the initial request. This allows users to have multiple
caches if they desire. In the smartcard reader you could use something
similar, since the file id also must be inherited or the environment
variable is useless.
In the X server situation, an atom could be created to hold this value
instead. The value is useless UNLESS the fileid has been inherited,
providing a second and third level protection against rogue users.
Protection levels as I have been using them:
First level: access only via socket created by login/pam.
Second level: socket only valid via process inheritance
Third level: automatic cleanup on logout
It doesn't prevent a trojan application though.
One issue that remains is undesired inheritance... This occurs
when an authorized administrator goes to root and starts/restarts some
services. The started services could inherit the socket.
In the Kerberos case, we just close the inherited file id in sudo. I
haven't looked at that particular code, but I think it just closes all
file ids from 3 to 1024.
Oh. On reading this back, I see I left out why/how the 1023 value...
Most systems limit the number of fileids that are valid to that
supported by the select system call. (IRIX doesn't...) We arbitrarily
picked FD_SETSIZE - 1. Starting with that number the Kerberos cache
server attempts to open it, and on failure subtracts one from the fid
being tested. When one is succesfully opened then a chiled is spawned to
become the cache server. The parent process then creates the environemnt
variable KRB5CCNAME with the value PIPE:fid, where fid is the opened
domain socket.
Using this allows other applications to use the default method of opening
file descriptors, and it won't interfere with most of those that use
the select system call with multiple descriptors (such as the X server)
because they will not have the Kerberos socket fid counted as part of the
set size in their controled FD_SET...
Paul is going to send out a diagram that describes this mechanism
and will hopefully clarify some of these issues.
that will help.
consider the problem of some visualization systems... Muliple graphic
displays are/can be installed in one system.
Two (or more) heads, each with a separate X server...
OK, so far this sounds like a Sun Ray server with multiple Sun Ray
thin clients, each which can have a Sun Ray session that lives in
the context of an X server connected to it.
Two users, two X servers (:0.0 and :1.0). Each at the end of about 100'
of fiber for video/keyboard/mouse.
I can also see this as a desktop system with multiple frame buffers,
each with either a separate X server or perhaps with a single X server
treating each frame buffer as an X screen (i.e. :0.0, :0.1, etc...).
That is only one X server... And the entire hardware set is at the users
desk. This is more like the old X terminal idea, but with more local
capabilities than just the X server. I think of them as between a full
workstation and an X terminal.
The best bet I can think of currently is to create a new Input module
for the X server. It would be controled/managed by the X server, but not
used for input or output OTHER THAN to direct/redirect/control the data
stream to/from the card reader and the pcsd server.
I think that your proposal assumes a single pcscd instance for the
whole system, whereas our proposal creates a separate pcscd instance
per X display (and hence per X server). Your proposal has the benefit
of allowing access to the same readers from multiple X displays, since
there is only one pcscd instance that controls all the IFD handlers,
and pcscd in that case can do access control from the clients based
on some criteria. I think you're saying that criteria is to use the
standard X access control mechanisms that already work for X clients
and, via a new XINPUT module, interface with pcscd to perform this
access control? Am I close :-)? How about a new XINPUT module that
a PAM module that is executing in the pcscd context talks to so that
we can continue to use PAM to actually control access using a more
extensible mechanism that people can write plug-in PAM modules for?
One of those PAM modules could be the "talk-to-XINPUT-smartcard-module"
PAM module. The bit that we still would have to figure out using the
single pcscd instance per system approach is how to specify which
readers are accessible to which X displays? In the Sun Ray case, it's
easy since we've made the decision that all readers connected to the
Sun Ray thin client belong to the Sun Ray session that is running
under the auspices of a particular X server, and we don't make any
provision to "share" a reader that is on one thin client with anyone
else, nor do we allow thin-client sessions access to readers connected
to the system board or other non-thin-client hardware; such access
can be provided via "helper daemons" that live outside the X server
and pcscd space.
right. Oh well. Maybe the method we used for Kerberos would help. It has
worked on all UNIX like systems we have done it on. That list
includes IRIX, Solaris, Linux, AIX, and HPUX (I think somebody has one).
For security purposes, it is normally a VERY good idea to abort the X
server and restart it for the next user.
Sure. In the Sun Ray case, we start one X server to handle login, and
we start a brand-spanking-new X server for each user upon successful
authentication.
yup. good practice.
This should allow the X login application to slave all input
(including the card reader) just as it slaves the keyboard
and mouse.
Well, if you have two truly independent X servers, and one keyboard
and one mouse (connected to the system's PS/2 or USB ports for
example), then only one of the X servers is going to be able to grab
the keyboard and mouse, and the other X server won't have one, unless
you do some special trickery where you can share your input devices
(clone device drivers that allow multiple opens on the same input
device for example).
I don't think these systems use USB (I haven't seen the internal hardware
of these systems, so it is possible there is a USP capability there, but
the systems themselves are remote from the display/keyboard/mouse). These
are primarily large compute servers that can perform real-time (very
nearly) image processing capabilities. They have multiple graphics heads
added, and a keyboard/mouse interface is available for each head.
This would also eliminate the problem of display control (which reader goes
with which graphic head) by allowing the hardware + X server to determine
the matching devices, just like it does for keyboard/mouse.
I don't understand how the hardware + X server determines which input
devices go with which X server instance (in the general case). I know
how that works on Sun Ray - we have a custom DDX that handles input
to the X server, so X server instances, Sun Ray thin clients and input
devices connected to the Sun Ray are all tightly bound via the DDX.
In the SGI IRIX case, it is done by configuration. Each keyboard/mouse
has a hardware provided interface which is bound to a specific graphics
head by configuration files.
It would also eliminate the problem of a user attaching to the device
without using the X server.
You may want to allow that in some cases though, although right now
I can't think of one that is compelling enough to want to figure out
how to make that work with your proposal :-)!
I'm beginning to think that the NRL Kerberos solution is better. At least
it is more flexible than an XINPUT module.
Just a thought.
This is good conversation, thanks (everyone) for bringing it up. I think
that this area of MUSCLE/pcscd has been sorely ignored for way too long,
and I'm glad to see that we're all starting to think about it more
seriously recently.
mike
[1] http://www.sun.com/sunray
--
[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
