From: Jesse I Pollard - CONTRACTOR (pollardcmf.nrl.navy.mil)
Date: Mon Oct 23 2006 - 09:57:44 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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/
>
> --
> Michael.Bendersun.com 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
> Musclelists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardcmf.nrl.navy.mil

Any opinions expressed are solely my own.

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]