Jesse I Pollard wrote:
Michael Bender wrote:
Jesse I Pollard wrote:
Hmmm... and how would you determine if the display is invalid?
We're adding PAM support to pcscd [...]
Seems rather special purpose and self limited. but ok.
Why do you say that? Do you think that access control should be
done in some other manner or in some other place, other than
pcscd?
{One pcscd instance per X server instance}
>
Having one for each server would work where only one server exists.
With multiple servers on a system you loose the socket identification.
Unless you use a different socket for each instance of course.
We have thought this through a bit, you know :-).
We're still looking at what transport is appropriate to use for
the Sun Ray/Solaris/Trusted Extensions case. We may be using
Internet Domain sockets or Doors, since UNIX domain sockets are
not available between a local zone and the global zone. Anyway,
the selection of available transports will be compile-time
options and the selection of which transport to use at runtime
may be either compiled in as well or based on some trusted
source such as a root-owned, globally-readable configuration
file that libpcsclite.so can access from within the context of
a local zone.
With that said, I need to say also that none of this stuff is
specific to Solaris/Trusted Extensions with the exception of
possibly including a transport that uses Doors. If we can get
away with using Internet Domain sockets then we'd prefer that
since it's more generic.
Sun Ray also runs on Linux, so whatever we do with PC/SC-lite
must also work in a Sun Ray environment that is running on the
several distros of Linux that we support.
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).
That scheme introduces another layer of administration and
configuration - Kerberos - that requires the site to deploy
Kerberos. We don't want to enforce any requirement like that,
since requiring Kerberos or PKI certs or any of the higher-level
authentication mechanisms that are cool in theory actually break
down in practice since you can't assume that a site is going to
setup a Kerberos infrastructure or a CA just so that they can
transfer a few APDUs between their browser and a smartcard reader.
One of the big reasons that we're not all using smartcards for
login and cryptography today is because all of the required
infrastructure is just such a big PITA to set up. At Sun, for
example, we have been working on a smartcard-based employee
badging system for physical facility access and logical access
to our internal networks, and it is a hard problem to move from
the single user on the desktop using a free cert from Thawte
to demo to the VP to actually rolling out certs for 40,000
people, handling certificate issuance and revocation, modifying
all applications to use something other than username/password
(and getting the damned window systems to do proper PAM
conversation functions!) and all the rest.
The project that Paul and I are working on is to provide users
on a multi-user system with secure access to smartcards and
smartcard readers that they are authorized to access, and that's
it. We're not trying to solve the world problem of ubiquitous
access to every smartcard reader on the planet, we're just
trying to make incremental changes to PC/SC-lite to make it
work better in a multi-user environment, without putting an
undue burden on the system administrators.
In your case at NRL, it sounds like you had to modify the X server
to create this special server process; did you make changes to one
or more of the X startup scripts to do that?
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.
That's OK, the library is going to change anyway, so I don't see an
issue with that. How the library and pcscd communicate with each other
is a private interface that is subject to change with each release.
The library function would have to use the domain socket to request a
> fileid that has been opened to the pcscd server.
When you say "fileid" are you talking about a "file descriptor"? If
so, file descriptors don't map across zones or even across privilege
levels necessarily, so a file descriptor value that makes sense to
the instance of pcscd won't necessarily be meaningful to an application
that is trying to talk to pcscd in a zone environment.
The whole Solaris Zones[1]/Trusted Extensions[2] scheme is really
designed to close a lot of holes that traditional UNIX has left open,
so some stuff that used to "just work" on a regular Solaris box now
don't "just work" by default (or by design).
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.
The only environment variable that we're using is $DISPLAY, and that
will serve as the index that the transport mechanism will use to
allow libpcsclite.so and pcscd to communicate. It might be that
we use $DISPLAY added to some base port number value to determine
which port number to use (as X does) - we're still working on that
part of the transport scheme. Whatever we do, we'll keep it simple
and keep the default to be that PC/SC-lite works the same way as it
does today so that we don't cause regressions.
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.
The big problem with doing anything with the X server such as
trying to read an atom is if a process has done an X server grab
(such as a lock screen process) then the X server will not respond
to the request to return the value of an atom. Coincidently, you
just might want to get that atom at screen lock time so that your
smartcard PAM module can talk to pcscd to do an authentication to
unlock the screen.
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.
OK then that's basically the Sun Ray model as it relates to X
resources - display, keyboard, mouse all bound by hardware. That
makes things much easier than trying to figure out a way to share
a common system keyboard/mouse.
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.
Thanks! Many TLA's have done a security analysis of Sun Ray and
have come to the same conclusion :-).
mike
[1] http://www.opensolaris.org/os/community/zones/
[2] http://www.opensolaris.org/os/community/security/projects/tx/
--
[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
