Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
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
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Ludovic Rousseau wrote: On 26/10/06, Michael Bender <[EMAIL PROTECTED]> wrote: >> Do you need to have different drivers for different zones >> or DTUs? Yes, we want to be able to give each instance of pcscd its own set of ifd handlers, so that, for example, if an instance of pcscd is running in a Sun Ray session, it will only know about the Sun Ray ifd handler for the internal reader in the Sun Ray DTU, while if an instance of pcscd is running for the console user, it will only know about the ccid USB ifd handler and the ifd handler for the console's internal reader. What would be the problem if a pcscd in a Sun Ray session also has access to a driver for a CCID reader? Nothing at all from a technical perspective. Some customers would want to prevent the pcscd instance running in a Sun Ray session from even being able to load the ccid (or any other) ifd handler. It would not use it (not even load it in memory) unless a CCID driver is connected to the Sun Ray. pcscd would just read the Info.plist of the driver. Unless you modified pcscd on this point. That was just an example. We actually would want both the Sun Ray DTU ifd handler and the ccid ifd handler to be available by default for a Sun Ray session. We might not want, say, an ifd handler for the system box reader to be available for a Sun Ray session. Is it possible to use the Sun Ray internal reader for session mobility and also connect an external smart card reader (say a CCID one) to use a smart card application like a PKCS#11 in Mozilla? Yes. 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
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Ludovic Rousseau wrote: On 26/10/06, Michael Bender <[EMAIL PROTECTED]> wrote: Ludovic Rousseau wrote: > Note that you can use IFDHGetCapabilities(..., > SCARD_ATTR_VENDOR_IFD_TYPE, ...) (or another similar tag) to check > that the IFD will understand the IFDHcontrol() request. What happens if you send an IFD an IFDHcontrol() request that it doesn't understand? Is it supposed to fail gracefully, or do IFDs tend to just start scribbling on random memory and then cause pcscd to dump core ;-)? The driver should return IFD_COMMUNICATION_ERROR as documented in [1] but it may also do anything else. I imagine you have the driver source code to correct any "deviant" behavior? Well, yes, I suppose that it was more of a rhetorical question. 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
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Jesse I Pollard - CONTRACTOR wrote: It can still be a spoof. The account may have been penetrated externally by a trojan, The user at the console ends up loosing the display because > his account has been taken over by some external means... Don't forget this one: The user might have shoved a peanut butter sandwich into the DVD-ROM slot and thus no one is able to use a DVD-ROM to update the system software anymore. This whole discussion is getting ridiculous. We are working on making PC/SC-lite work properly in a multi-user environment, not trying to fix every conceivable security hole that UNIX has ever had or that it may ever develop. 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
Re: Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
On 26/10/06, Michael Bender <[EMAIL PROTECTED]> wrote: >> Do you need to have different drivers for different zones >> or DTUs? Yes, we want to be able to give each instance of pcscd its own set of ifd handlers, so that, for example, if an instance of pcscd is running in a Sun Ray session, it will only know about the Sun Ray ifd handler for the internal reader in the Sun Ray DTU, while if an instance of pcscd is running for the console user, it will only know about the ccid USB ifd handler and the ifd handler for the console's internal reader. What would be the problem if a pcscd in a Sun Ray session also has access to a driver for a CCID reader? It would not use it (not even load it in memory) unless a CCID driver is connected to the Sun Ray. pcscd would just read the Info.plist of the driver. Unless you modified pcscd on this point. Is it possible to use the Sun Ray internal reader for session mobility and also connect an external smart card reader (say a CCID one) to use a smart card application like a PKCS#11 in Mozilla? Regards, -- Dr. Ludovic Rousseau ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
On 26/10/06, Michael Bender <[EMAIL PROTECTED]> wrote: Ludovic Rousseau wrote: > Note that you can use IFDHGetCapabilities(..., > SCARD_ATTR_VENDOR_IFD_TYPE, ...) (or another similar tag) to check > that the IFD will understand the IFDHcontrol() request. What happens if you send an IFD an IFDHcontrol() request that it doesn't understand? Is it supposed to fail gracefully, or do IFDs tend to just start scribbling on random memory and then cause pcscd to dump core ;-)? The driver should return IFD_COMMUNICATION_ERROR as documented in [1] but it may also do anything else. I imagine you have the driver source code to correct any "deviant" behavior? Bye, [1] http://pcsclite.alioth.debian.org/ifdhandler-3/node18.html -- Dr. Ludovic Rousseau ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Paul Klissner wrote: Ludovic Rousseau wrote: Why do you have: "The IFD handler plugin directory location >> specified in argv[]"? The current thinking is to pass in a base directory into argv[] where pcscd will find it's other configuration files, such as reader.conf, and what, by default, goes into /var/run. This is because we are creating a daemon for each client session, each requiring it's own unique repository for private non-shareable data. i.e. we'll add a few command-line switches to pcscd so that the invocation would look like this: /usr/bin/pcscd -B /tmp/SUNWut/pcscd/7 -i /opt/PCSC/ifdhandlers (ignore the specific option letters and directories, these are just examples to illustrate the point). >> Do you need to have different drivers for different zones >> or DTUs? Yes, we want to be able to give each instance of pcscd its own set of ifd handlers, so that, for example, if an instance of pcscd is running in a Sun Ray session, it will only know about the Sun Ray ifd handler for the internal reader in the Sun Ray DTU, while if an instance of pcscd is running for the console user, it will only know about the ccid USB ifd handler and the ifd handler for the console's internal reader. Of course all of this is configurable at runtime, and these are just examples to illustrate the point. The default operation of pcscd, i.e. with none of the new command line switches specified, will be to operate just as it does today, we won't be changing any of the default directories or files that it creates or uses. 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
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Ludovic Rousseau wrote: I think it is better to use IFDHcontrol(). At least the communication is more explicit. I agree. Note that you can use IFDHGetCapabilities(..., SCARD_ATTR_VENDOR_IFD_TYPE, ...) (or another similar tag) to check that the IFD will understand the IFDHcontrol() request. What happens if you send an IFD an IFDHcontrol() request that it doesn't understand? Is it supposed to fail gracefully, or do IFDs tend to just start scribbling on random memory and then cause pcscd to dump core ;-)? 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
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Ludovic Rousseau wrote: On 25/10/06, Paul Klissner <[EMAIL PROTECTED]> wrote: Just in time for another diagram update: http://www.freemyimage.com/ims/pic.php?u=1500BLfhm&i=15920 Why do you have: "The IFD handler plugin directory location specified in argv[]"? Do you need to have different drivers for different zones or DTUs? Bye, The current thinking is to pass in a base directory into argv[] where pcscd will find it's other configuration files, such as reader.conf, and what, by default, goes into /var/run. This is because we are creating a daemon for each client session, each requiring it's own unique repository for private non-shareable data. I have to let Mike answer why the plan was to indicate the IFD handler directory with a separate runtime specifier. That's his idea, and I'm not totally positive was to why. I think the goal is to be able to optionally put all of the pcscd data in it's own unique directory tree, so that although there would be only one copy of the IFD handlers, symbolic links to them could be put in each pcscd's data directory tree, I supposed for the sake of simplicity, locality, architectural elegance or something. Paul ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Ludovic Rousseau wrote: On 25/10/06, Paul Klissner <[EMAIL PROTECTED]> wrote: Just in time for another diagram update: http://www.freemyimage.com/ims/pic.php?u=1500BLfhm&i=15920 Instead of putenv(), the goal now is to use IFDHcontrol() to pass a new control code designed can be tolerated by all IFD Handlers to pass in a client cred structure that includes X display info, EUID, EGID, and possibly other info. I think it is better to use IFDHcontrol(). At least the communication is more explicit. Note that you can use IFDHGetCapabilities(..., SCARD_ATTR_VENDOR_IFD_TYPE, ...) (or another similar tag) to check that the IFD will understand the IFDHcontrol() request. Bye, Thanks. That is very useful information. That really helps clean up the approach. putenv() was a less desireable fallback for not knowing how to easily address the compatibility problem. Glad there is a straightforward way to handle it. Paul ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
On 25/10/06, Paul Klissner <[EMAIL PROTECTED]> wrote: Just in time for another diagram update: http://www.freemyimage.com/ims/pic.php?u=1500BLfhm&i=15920 Why do you have: "The IFD handler plugin directory location specified in argv[]"? Do you need to have different drivers for different zones or DTUs? Bye, -- Dr. Ludovic Rousseau ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
On 25/10/06, Paul Klissner <[EMAIL PROTECTED]> wrote: Just in time for another diagram update: http://www.freemyimage.com/ims/pic.php?u=1500BLfhm&i=15920 Instead of putenv(), the goal now is to use IFDHcontrol() to pass a new control code designed can be tolerated by all IFD Handlers to pass in a client cred structure that includes X display info, EUID, EGID, and possibly other info. I think it is better to use IFDHcontrol(). At least the communication is more explicit. Note that you can use IFDHGetCapabilities(..., SCARD_ATTR_VENDOR_IFD_TYPE, ...) (or another similar tag) to check that the IFD will understand the IFDHcontrol() request. Bye, -- Dr. Ludovic Rousseau ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Michael Bender wrote: Jesse I Pollard wrote: (about 50,000,000,000,000 lines of text) Paul Klissner wrote: (another 50,000,000,000,000 lines of text) Geeze guys! I go away for a weekend to Tahoe and you guys write War and Peace on the MUSCLE list :-). I'll read everything that was written but it will take a few days to wade through it all :-). Just in time for another diagram update: http://www.freemyimage.com/ims/pic.php?u=1500BLfhm&i=15920 Instead of putenv(), the goal now is to use IFDHcontrol() to pass a new control code designed can be tolerated by all IFD Handlers to pass in a client cred structure that includes X display info, EUID, EGID, and possibly other info. Paul ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Jesse I Pollard wrote: (about 50,000,000,000,000 lines of text) Paul Klissner wrote: (another 50,000,000,000,000 lines of text) Geeze guys! I go away for a weekend to Tahoe and you guys write War and Peace on the MUSCLE list :-). I'll read everything that was written but it will take a few days to wade through it all :-). 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
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Jesse I Pollard - CONTRACTOR wrote: therefore, the process doing the putenv would have a valid zone, and a spoofed dpy#. I'm talking about Solaris Containers (aka. Zones), which is part of Solaris 10 and documented on the Internet. I think you are using Zones as a different kind of abstraction. But the architectural changes being proposed for pcscd don't require Solaris Containers (Zones), nor do they require Solaris Trusted Extensions. So the zone the X server+XDM are running in is unavailable to any process logging into the server without the SunRay ??? If that is true, then the only thing that can happen is a denial of service. But the online documentation doesn't describe it that way. It describes zones as a method of partitioning a server into sections with different dedicated uses. That implies that a user can login to a system, and get the same zone no matter where the login comes from (two or more logins for the same user). If this second login is a hijacked connection or from a penetrated system, then the users credentials are already lost. Only access to the smartcard is left. Zones in themselves are a security mechanism. They are like 'chroot' but for everything. A zone is a whole virtual machine. If you break into a zone, it is like breaking into jail. You can't damage anything outside of the zone. Further, zones are cloneable so if a zone is damaged it can be reinstantiated in its original state easily. Trusted Extensions adds a lot of security on top of that by creating zones and along with the a concept of labels. File systems are mounted differently and all resources are scrutinized and guarded based on labels. Think of a label as a security level, like 'top-secret'. Thus labels have a sensitivity rating, and label sensitivity is always checked. There's no way for a local zone to access data in another local zone or the global zone in a default configuration. Security is extremely tight. But Trusted Extensions is deep subject about a pending s10 product which has just received high security clearances by important review bodies. You'll have to let me leave it at that for now. Just assume that a 'local zone' is highly isolated and that all interactions, if allowed are extremely judiciously controlled. The PAM module runs as root in the same context as the server not the client. It doesn't matter if the client spoofs anything, server-side PAM figures out if what it got is valid before authenticating the client to use that particular instance of pcscd. The PAM module runs as root in the context of XDM, not the X server. After PAM authorizes XDM to give the user a login, the existing X server is terminated, and a new one started for the user Different PAM module. Our design includes a pcscd pam module which has it's own PAM stack, thus authenticating different items for a different component. The X PAM stuff is resolved earlier. dtlogin can be a client of pcscd, but uses a different PAM module to login the user. From the standpoint of pcscd, it's PAM module need only authenticate that for any SCardEstablishSession() call that the owner of the Xdpy# is valid. How the PAM module does it depends on the system. We have one that works in the Sun Ray environment, and will provide one that authenticates everything so no regression is introduced. Anyone is free to augment pcscd's PAM authentication check on the xdpy# any way they want. The vulnerable window is here. The PAM module has given pcsd the dpy# from the server used to enter the login information. The dpy# is passed to pcscd over the socket or door, and then pcscd invokes it's own PAM module to authenticate it. Thus, if dtlogin needs to be a client of pcscd, pcscd must validate that dtlogin's UID owns the display at the time of access, when it goes away and the new X session is started, then if a client of that needs to access pcscd, the authentication check is made again against that xdpy# and uid. Not the new one given to the user (they may have the same number though). That is a new process and must allocate port 6000 starting from scratch, and has no security connection to the other. Of course, if XDM doesn't abort the server first, then there is no window of opportunity to grab the port, and I completely misunderstood. The XDM process I've been using aborts the X server after login, and again when the user logs out. Originally (at least under solaris 2.x, x <= 8) this was done because XDM (running as root) would start the X server (also running as root). Then the XDM process would and start the login procedure. After the user is authenticated, but before the user process was started, it would abort the X server, set ownership/whatever for the display device to the new user, switch to the users credentials, and start a new X server (the new one would be running with the users credentials) along with setting the X authority for the server/X authority file and finally setting th
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
- Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. On Tue, 24 Oct 2006, Paul Klissner wrote: Jesse I Pollard - CONTRACTOR wrote: On Mon, 23 Oct 2006, Paul Klissner wrote: 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. Look over to the block of text on the right of the rightmost ifd handler diagram... it mentions putenv() is the mechanism. Yes, but putenv from a user controled item is an untrustworthy source. putenv() is issued by pcscd in pcscd's own root-owned environment, which is shared by the IFD handler dynamic library. No unprivileged user can touch it. It is seperate from the client environment. The ifd and pcscd cannot determin if the Xdpy# value is beeing spoofed. Yes they can. That's what the PAM module is all about. The ifd handler assumes pcscd has authenticated the xdpy#, ie. that pcscd has verified that the xdpy# is owned by the UID of a client in the correct zone. Beyond that, if by spoofable, you mean someone hacks the kernel or acquires access to the global as root... hey, if someone can hack into the system as root, security on the machine is FUBAR anyway. It can still be a spoof. As I understand it - any login - (right now, my example would be based on ssh) will get a valid zone. The account may have been penetrated externally by a trojan, and the user is making an unknown ssh login to gain access to the host. therefore, the process doing the putenv would have a valid zone, and a spoofed dpy#. I'm talking about Solaris Containers (aka. Zones), which is part of Solaris 10 and documented on the Internet. I think you are using Zones as a different kind of abstraction. But the architectural changes being proposed for pcscd don't require Solaris Containers (Zones), nor do they require Solaris Trusted Extensions. So the zone the X server+XDM are running in is unavailable to any process logging into the server without the SunRay ??? If that is true, then the only thing that can happen is a denial of service. But the online documentation doesn't describe it that way. It describes zones as a method of partitioning a server into sections with different dedicated uses. That implies that a user can login to a system, and get the same zone no matter where the login comes from (two or more logins for the same user). If this second login is a hijacked connection or from a penetrated system, then the users credentials are already lost. Only access to the smartcard is left. The PAM module runs as root in the same context as the server not the client. It doesn't matter if the client spoofs anything, server-side PAM figures out if what it got is valid before authenticating the client to use that particular instance of pcscd. The PAM module runs as root in the context of XDM, not the X server. After PAM authorizes XDM to give the user a login, the existing X server is terminated, and a new one started for the user. The vulnerable window is here. The PAM module has given pcsd the dpy# from the server used to enter the login information. Not the new one given to the user (they may have the same number though). That is a new process and must allocate port 6000 starting from scratch, and has no security connection to the other. Of course, if XDM doesn't abort the server first, then there is no window of opportunity to grab the port, and I completely misunderstood. The XDM process I've been using aborts the X server after login, and again when the user logs out. Originally (at least under solaris 2.x, x <= 8) this was done because XDM (running as root) would start the X server (also running as root). Then the XDM process would and start the login procedure. After the user is authenticated, but before the user process was started, it would abort the X server, set ownership/whatever for the display device to the new user, switch to the users credentials, and start a new X server (the new one would be running with the users credentials) along with setting the X authority for the server/X authority file and finally setting the DISPLAY environment variable to start the Xsession for the user. Even adding a zone box around the X server and XDM wouldn't prevent a grab of port 6000 between XDM aborting the login X server, and starting the users X server. So as long as the other process cannot get the equivalent zone via other non-Sun Ray logins, there shouldn't be a problem. It does create problems for users that need shared access between different Sun Ray boxes using the same login. Wel maybe. But that has nothing to do with the smartcard reader. The user at the console
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Jesse I Pollard - CONTRACTOR wrote: On Mon, 23 Oct 2006, Paul Klissner wrote: 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. Look over to the block of text on the right of the rightmost ifd handler diagram... it mentions putenv() is the mechanism. Yes, but putenv from a user controled item is an untrustworthy source. putenv() is issued by pcscd in pcscd's own root-owned environment, which is shared by the IFD handler dynamic library. No unprivileged user can touch it. It is seperate from the client environment. The ifd and pcscd cannot determin if the Xdpy# value is beeing spoofed. Yes they can. That's what the PAM module is all about. The ifd handler assumes pcscd has authenticated the xdpy#, ie. that pcscd has verified that the xdpy# is owned by the UID of a client in the correct zone. Beyond that, if by spoofable, you mean someone hacks the kernel or acquires access to the global as root... hey, if someone can hack into the system as root, security on the machine is FUBAR anyway. It can still be a spoof. As I understand it - any login - (right now, my example would be based on ssh) will get a valid zone. The account may have been penetrated externally by a trojan, and the user is making an unknown ssh login to gain access to the host. therefore, the process doing the putenv would have a valid zone, and a spoofed dpy#. I'm talking about Solaris Containers (aka. Zones), which is part of Solaris 10 and documented on the Internet. I think you are using Zones as a different kind of abstraction. But the architectural changes being proposed for pcscd don't require Solaris Containers (Zones), nor do they require Solaris Trusted Extensions. The PAM module runs as root in the same context as the server not the client. It doesn't matter if the client spoofs anything, server-side PAM figures out if what it got is valid before authenticating the client to use that particular instance of pcscd. The user at the console ends up loosing the display because his account has been taken over by some external means... Now the spoofed dpy# is passed to ifd, and still with the valid zone of the login. Administering the system to be secure from hacking is outside of the scope of pcscd. Whenever someone assumes the identity of another user on the system, then they can do all kinds of things on behalf of the stolen identity. But that is not not really germane to a our discussion about pcscd. How is that an indictment of the architecture being proposed? Therefore the ifd cannot verify that the dpy# is correct. It IS matched against a valid zone. One way this may not work is if zone defintions on the server are different depending on how the user logs in. Unfortunately, this may also prevent the user from accessing his data, which likey has the same labeling... Again, I think there is some confusion in terms. Zones are Solaris Containers (available in Solaris 10), and are not directly related to the proposed pcscd architectural changes. They are used by Solaris Trusted Extensions, which is used to help enforce our our particular security model for highly secure environments. Somehow I feel like this discussion is going in circles, and the scope has gotten unfocused,... like we're recklessly shifting metaphors and layers, and therefore losing sight of the key elements directly relevant to pcscd. For my vulerability example above, I am assuming the ssh login to the server gets the same zone defintion that the user would get when logging in from the Sun Ray box. The security details outside of pcscd and the mechanisms of sockets (or Solaris doors), PAM, and putenv() require an understanding of Solaris Zones and Solaris Trusted Extensions. I'm not sure if Solaris Trusted Extensions has been productized just yet, but will be soon. In a Trusted Extensions enabled system running Zones, the Global Zone is *highly* secure, and the potentially outward facing 'local' zones, are called 'labelled' zones, and they are extremely contained and all accesses limited by policy and scrutinized heavily. The very way they are built is inherently secure. That is where the clients live. They can't touch the global zone when it is configured properly. Therefore guarding the pcscd interface with PAM to validate what the client sends over the socket or door should constitute sufficient security in that regard. Umm PAM does no validation other than the initial connection. "..valdate what the client sends.." implies it is doing content analysis, and to my knowlege, PAM cannot do this. PAM can validate the PAM_USER with the PAM_AUTHTOK. This can be made to fit the authentication scenario. You do show where the zone label comes
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
On Mon, 23 Oct 2006, Paul Klissner wrote: 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. Look over to the block of text on the right of the rightmost ifd handler diagram... it mentions putenv() is the mechanism. Yes, but putenv from a user controled item is an untrustworthy source. The ifd and pcscd cannot determin if the Xdpy# value is beeing spoofed. Yes they can. That's what the PAM module is all about. The ifd handler assumes pcscd has authenticated the xdpy#, ie. that pcscd has verified that the xdpy# is owned by the UID of a client in the correct zone. Beyond that, if by spoofable, you mean someone hacks the kernel or acquires access to the global as root... hey, if someone can hack into the system as root, security on the machine is FUBAR anyway. It can still be a spoof. As I understand it - any login - (right now, my example would be based on ssh) will get a valid zone. The account may have been penetrated externally by a trojan, and the user is making an unknown ssh login to gain access to the host. therefore, the process doing the putenv would have a valid zone, and a spoofed dpy#. The user at the console ends up loosing the display because his account has been taken over by some external means... Now the spoofed dpy# is passed to ifd, and still with the valid zone of the login. Therefore the ifd cannot verify that the dpy# is correct. It IS matched against a valid zone. One way this may not work is if zone defintions on the server are different depending on how the user logs in. Unfortunately, this may also prevent the user from accessing his data, which likey has the same labeling... For my vulerability example above, I am assuming the ssh login to the server gets the same zone defintion that the user would get when logging in from the Sun Ray box. The security details outside of pcscd and the mechanisms of sockets (or Solaris doors), PAM, and putenv() require an understanding of Solaris Zones and Solaris Trusted Extensions. I'm not sure if Solaris Trusted Extensions has been productized just yet, but will be soon. In a Trusted Extensions enabled system running Zones, the Global Zone is *highly* secure, and the potentially outward facing 'local' zones, are called 'labelled' zones, and they are extremely contained and all accesses limited by policy and scrutinized heavily. The very way they are built is inherently secure. That is where the clients live. They can't touch the global zone when it is configured properly. Therefore guarding the pcscd interface with PAM to validate what the client sends over the socket or door should constitute sufficient security in that regard. Umm PAM does no validation other than the initial connection. "..valdate what the client sends.." implies it is doing content analysis, and to my knowlege, PAM cannot do this. You do show where the zone label comes from (socket credentials from the kernel) But you cannot get the Xdpy# that way. Right. The Xdpy is sent by the library over the socket or door interface (we're still weighing which is ideal among doors/sockets). It doesn't have to be valid. The PAM module uses the un-spoofable EUID and zone label, and then it checks to see if the client owns whatever X display # was passed through the transport. If the client really owns the display the display is authenticated, otherwise it is rejected. Thats my point. The client DOES own the display. It just happens that the ownership shouldn't exist. Another question (though not really a security one) - what happens when one userhas two Sun Ray displays at a desk? We're not addressing the multi-head Sun Ray client scenario at the moment, but we do pass the X sub-display number up to pcscd. As far as multiple Sun Ray clients logged in by the same user goes, I suppose it is a conceivable that a user could go to great lengths to shoot themselves in the foot that way by spoofing themselves, but a good security policy regarding UID assigments to users would prevent abuse of other user's security. But let's face it, anyone can engage in self-destructive behaviors. If someone wants to work hard at sabotaging themselves, that's their choice. Not multi-head - Just two Sun Ray client systems, two separate system boxes with a keyboard/mouse/display/smartcard reader for each box. Some of our developers use this for configuration for the monitoring and debugging that are being run on a different workstation. 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,
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
BTW: I made a few changes based on your feedback. The web hosting site forced me to change the URL to access it, here: http://www.freemyimage.com/ims/pic.php?u=1500BLfhm&i=15879 Unfortunately, I can't include all of the details step-by-step in the diagram. Hopefully it won't be too much of a hassle to associate descriptions in the e-mails with the illustration to get some of the finer points. Paul 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. The ifd and pcscd cannot determin if the Xdpy# value is beeing spoofed. You do show where the zone label comes from (socket credentials from the kernel) But you cannot get the Xdpy# that way. Another question (though not really a security one) - what happens when one userhas two Sun Ray displays at a desk? 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...) Right now, we have users doing this. One display is holding the "official" windows of his application, the other X server is recieving debug output monitoring the application. These users have two (or more) keyboard/mouse/display devices on the desk (I have two, one Linux and one Solaris). 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 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. ___ 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 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
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. Look over to the block of text on the right of the rightmost ifd handler diagram... it mentions putenv() is the mechanism. The ifd and pcscd cannot determin if the Xdpy# value is beeing spoofed. Yes they can. That's what the PAM module is all about. The ifd handler assumes pcscd has authenticated the xdpy#, ie. that pcscd has verified that the xdpy# is owned by the UID of a client in the correct zone. Beyond that, if by spoofable, you mean someone hacks the kernel or acquires access to the global as root... hey, if someone can hack into the system as root, security on the machine is FUBAR anyway. The security details outside of pcscd and the mechanisms of sockets (or Solaris doors), PAM, and putenv() require an understanding of Solaris Zones and Solaris Trusted Extensions. I'm not sure if Solaris Trusted Extensions has been productized just yet, but will be soon. In a Trusted Extensions enabled system running Zones, the Global Zone is *highly* secure, and the potentially outward facing 'local' zones, are called 'labelled' zones, and they are extremely contained and all accesses limited by policy and scrutinized heavily. The very way they are built is inherently secure. That is where the clients live. They can't touch the global zone when it is configured properly. Therefore guarding the pcscd interface with PAM to validate what the client sends over the socket or door should constitute sufficient security in that regard. You do show where the zone label comes from (socket credentials from the kernel) But you cannot get the Xdpy# that way. Right. The Xdpy is sent by the library over the socket or door interface (we're still weighing which is ideal among doors/sockets). It doesn't have to be valid. The PAM module uses the un-spoofable EUID and zone label, and then it checks to see if the client owns whatever X display # was passed through the transport. If the client really owns the display the display is authenticated, otherwise it is rejected. Another question (though not really a security one) - what happens when one userhas two Sun Ray displays at a desk? We're not addressing the multi-head Sun Ray client scenario at the moment, but we do pass the X sub-display number up to pcscd. As far as multiple Sun Ray clients logged in by the same user goes, I suppose it is a conceivable that a user could go to great lengths to shoot themselves in the foot that way by spoofing themselves, but a good security policy regarding UID assigments to users would prevent abuse of other user's security. But let's face it, anyone can engage in self-destructive behaviors. If someone wants to work hard at sabotaging themselves, that's their choice. 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...) Right now, we have users doing this. One display is holding the "official" windows of his application, the other X server is recieving debug output monitoring the application. These users have two (or more) keyboard/mouse/display devices on the desk (I have two, one Linux and one Solaris). Solaris Trusted Extensions is a profoundly secure environment, wherein filtering is enabled in the kernel and the X server is secured. That will be in forthcoming update of Solaris. I'm sure you'll want to dig into that documentation and try to set one of those systems up if security is your thing. It is for people like you Trusted Extensions was designed. 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. Ah, perhaps this explains your last question. OK, maybe I could make it clearer... Each local zone is a Trusted Extensions *highly* secure environment (zone) that uses a concept of zone 'label' sensitivity, and checks every network and device access. Even cut/paste operations on the desktop are monitored. Their goal is to make hacking impossible, and to protect extremely critical information. a1, b1, c1, a2, b2, c2 each refer to a unique Sun Ray desktop unit, and each Sun Ray talks to one and only one pcscd daemon stack (just couldn't draw them all on the diagram, so I had to indicate it). Perhaps I should add a note that says Sun Ray or X Display for each terminal display in the Local Zones. The diagram also only illustrates the static result of all decisions made, and alm
Re: [Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
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. The ifd and pcscd cannot determin if the Xdpy# value is beeing spoofed. You do show where the zone label comes from (socket credentials from the kernel) But you cannot get the Xdpy# that way. Another question (though not really a security one) - what happens when one userhas two Sun Ray displays at a desk? 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...) Right now, we have users doing this. One display is holding the "official" windows of his application, the other X server is recieving debug output monitoring the application. These users have two (or more) keyboard/mouse/display devices on the desk (I have two, one Linux and one Solaris). 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 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. ___ 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
[Muscle] Revised Diagram: pcsclite for Sun Ray w/Solaris Trusted Exteions
Here's a link to an improved diagram: http://www.freemyimage.com/ims/pic.php?u=1500BLfhm&i=15663 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
