Jesse I Pollard - CONTRACTOR wrote:
Michael Bender wrote:
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.
Huh? So are you saying that the *library* is now responsible for
starting the pcscd daemon?
> This is the only change needed
Cool, then please describe this simple change that will make the
existing pcscd/libpcsclite.so work properly on a Sun Ray server
running under Solaris 10 with Trusted Extension enabled.
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.
piffle to you. Sure they can with help from the proper infrastructure
such as an identity manager, Kerberos deployment or other back-end
help.
That and the lack of source code for accessing the reader.
OK, that's a new one to me. What source code do you think is
lacking? Is there some piece of the MUSCLE project that isn't
available in source? Is there some Linux code that is not
available in source that prevents using smartcards in an
enterprise for authentication?
> So far, all implementations use something else.
OK, what else do they use?
Both windows and UNIX based systems currently are using/planning
on using the Kerberos foundation.
I don't think that's accurate. I think that the best that anyone
can say is that Windows and UNIX systems provide the ability to
enable the use of Kerberos, but whether or not Kerberos or any
other distributed authentication mechanism is used depends on the
system administrator and the site security policy.
> 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 received by every child process.
We can't use UNIX domain sockets to cross the local<->global zone
boundary. A local zone really does look a like like it's own virtual
machine[1] and so a lot of the traditional mechanisms that UNIX
code uses today to do client<->daemon communication don't work
across zone boundaries.
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.
$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. The UID can
not be spoofed (without hacking the kernel and socket interfaces).
That is for *Sun Ray*, as I've said all along, since the access
control is done via PAM, anyone can do whatever other checks they
want to do in a non-Sun Ray environment by writing the appropriate
PAM module. If you want to user Kerberos for the console user, then
by all means, write a PAM module that can check the ticket for the
caller. What other data do you need a PAM module to see in order to
do this other than UID (trusted), pid (trusted) and $DISPLAY
(untrusted) of the caller?
What is your concern with this approach? The work that Paul and I
are doing doesn't mandate any security/access control policy at
all, which is why we picked PAM to use in pcscd rather than hard
code some policy that we think is useful.
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.
Your scheme assumes that the fileid is valid between the client
and the daemon, and as I wrote above, in a zones environment, it
is not.
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.
It does on Xsun, I'm not sure about Xorg.
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.
Which process is that? Do you mean the screen locking program?
If so, that's the program that has the server grab, and (modulo
bugs in that code) it's the only process that can ask the X server
for an atom without blocking until the grab is released. That
scheme breaks down if you use a helper process that needs to get
access to that atom.
Anyway, I don't understand why smartcard code needs to get any
information from the X server. I really don't want to couple
PC/SC-lite to X in any way other than using $DISPLAY, which is
really just an arbitrary untrusted key that's not specifically
related to X.
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.
What is the race condition that you're referring to?
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.
What do you mean by "external use"?
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.
Sure, and we don't trust $DISPLAY at all.
mike
[1] http://www.opensolaris.org/os/community/zones/faq/
--
[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
