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, 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.
Off topic idle question -- Isn't this derived from the former Sun CMW
workstation? I have done a little with that product some years ago. We
didn't use it mostly because it was way too difficult to configure for
a single sign-on environemnt. There was also the problem that the X server
could not keep up with the X functionality. Hopefully, you found the new
X server security module capability sufficient to use.
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 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.
Hopefully those depictions have been addressed by this and
former e-mails. The diagram was meant to augment the discussion
with a summary view, not be a full detailed explanation, which
starts to go outside of the scope of this list's discussion.
Our goal is to use standard non-sunray specific mechanisms
in pcsc-lite. Except for possibly creating a choice of transport
types, we've managed to design our adaptations that way.
Somewhat. It has narrowed the location of where I think a vulnerability
may lie.
Paul
_______________________________________________
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
