On Fri, 20 Oct 2006, Michael Bender wrote:
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.
No - only the solution is similar. No need for Kerberos to implement
the METHOD of inheritance. All changes would be done in the library
using/starting the pscd daemon. This is the only change needed - it
would be an extension/modification of the existing function that
connectes using a TCP socket, and the function that the pscd daemon
uses to initialize the daemon.
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.
piffle. The real problem is that the smartcards cannot provide
distributed authentication. That and the lack of source code for
accessing the reader. So far, all implementations use something
else. Both windows and UNIX based systems currently are using/planning
on using the Kerberos foundation.
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?
Don't need to.
That said - because of the number of platforms that needed it, I couldn't
quite use PAM due to the incompatable interfaces and lack of
documentation. On Linux alone (which is the same as Solaris PAM, I
believe) it isn't necessary.
The Kerberos PAM module was built with an extended/modified version of the
file cache startup. And that modification is strictly within PAM. The
Cache initialization call needed to be modified. The returned value is the
file id to use for all clients - the PAM authorization module had to
define the environment variable in a slightly different way. Total changes
in PAM are about 12 lines. No changes to XDM required. Kerberos got a
more significant change (a new cache type). After that, even Kerberos had
a minimal change. A new table entry in the cache type list. A total of
about 1747 lines (I have the source for it, since supporting NRLs use
of kerberos is what I do).
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.
Unfortunately, the user controls that piece of data. And that makes it
untrustworthy for a security key. The advantage our model has is that
the environment data isn't used for security checks. You cannot access
the cache unless the inheritance of the socket fileid is also valid. And
that is maintained by the kernel. In this form, the environemnt varible
is irrelevent. The kernel (and cache daemon) don't care.
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.
First,I don't believe an X server grab affects X resource queries.
Second, the process that is talking to the X server about unlocking
the screen is definitely not blocked. That process is the only one
that needs the atom.
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.
Thats what I thought. The only thing left is what to do about the race
condition between restarts of the X server. In the normal case - it isn't
a problem if the user does loose control. Well, it may be a denial of
service, but no user data or system data is compromized.
Using the X display number maching against authorized connection to the
same display is not secure for external use. That isn't what the
Xserver was designed for.
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 :-).
The only caution I have is in making a security related decision based
on uncontroled data (the X display number). This datum is only valid
in the context of the user. It is NOT secure.
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
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
