Jesse I Pollard - CONTRACTOR wrote:
On Fri, 20 Oct 2006, Paul Klissner wrote:
Here's a link to an improved diagram:
http://www.freemyimage.com/ims/pic.php?u=1500BLfhm&i=15663
That helps. And the diagram does omit how the xdpy# is generated to
even be available to ifd handler. This is the only weakness I see.
xdpy# comes from the caller of libpcsclite.so. Whatever the results
of a getenv("DISPLAY") are gets parsed in the library and the parsed
results are sent to the appropriate pscsd instance (after some sanity
checking in the library).
The ifd and pcscd cannot determin if the Xdpy# value is beeing spoofed.
The ifd trusts that the Xdpy# sent from pcscd has been authenticated.
The ifd does not need to make access control decisions. pcscd does
that.
pcscd does that via PAM. PAM does that via specific PAM modules. We
are writing one for Sun Ray. We are also writing one for the default
case of no access restrictions so that the default behavior of pcscd
is the same as it is today (i.e. everyone gets access to all the
readers).
The X server, XDM, ssh, and peanut butter sandwiches are in no way
involved in any of this.
You do show where the zone label comes from (socket credentials from
the kernel) But you cannot get the Xdpy# that way.
Yes, that is absolutely correct. We can not get the Xdpy# from
socket credentials.
Another question (though not really a security one) - what happens
> when one user has two Sun Ray displays at a desk?
Sun Ray uses the username as one of the keys in identifying a
Sun Ray session (it also uses other mechanisms as well). What
that means is that the same username can only have one Sun Ray
session associated with that username on a Sun Ray server at
one time, i.e. the user "joesmith" can't have more than one
Sun Ray session associated with his username. Sun Ray has a
mode that associates either the MAC address of the DTU or a
token ID read from a smartcard (note that this is *not* using
authenticated smartcard access, this is simply using a token
read from the card to associate with a session) and in those
two cases, multiple sessions can be logged in with the same
UNIX username, although to the Sun Ray server, they are each
separate, unique sessions.
I can see this happening more on a developers desk instead of a normal
users desk - Both systems may need the smartcard simultaneously. There
is also the possibility of cross matched zones (both belong to the user,
both X servers belong to the same user, and for some reason, the user
chooses to send a X window to the other display...)
Whatever the value of $DISPLAY is at the time that SCardEstablishContext
is called will be used to connect to the appropriate pcscd instance.
If the UID of the caller is allowed to access that X display, then
they also get access to the reader. The same way that it works when
you fire up an xterm.
Btw, The diagram does leave out one other piece of info:
I assume each box at the bottom represents a SunRay display/system, and
the single box on top is the remote server system.
The box labeled "Sun Ray DTU" represents the Sun Ray thin client, the
thing that sits on your desk and to which you attach a display, keyboard
and mouse, and which has an internal smartcard reader.
The boxes labeled "xxx zone" refer to instances of local zones that
Sun Ray sessions run in. Other than the DTU, all of the rest of this
stuff lives on the Sun Ray server, a box running Solaris or Linux.
The diagram also only illustrates the static result of all decisions made,
and almost non none of the steps to get that way. I think those steps
and the security decisions required to procede from state to state are
needed to fill out the security table of data source/allowed
state/destination state. I think that would show that the Xdpy# is
an uncontroled datum being used for security decisions.
So are we now doing a full security review for FIPS certification
here on the MUSCLE list such that all documentation, including
diagrams, must be provided down to the last detail?
mike
--
[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
