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 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.
I don't understand what you mean. If I log into a desktop,
for the duration of that session, doesn't that session own
the display?
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.
Each get's it's own pcscd chain. They are isolated.
Some of our developers use this for configuration for the monitoring and
debugging that are being run on a different workstation.
We're initially doing this in the configuration illustrated to allow
for tight security, which might require a different approach for
different situations, or might need to be extended. The point is,
what we're doing with pcscd does not preclude the environment you
refer to, since a pass-all PAM module can be put in place, and
then you end up with primarily exactly the same functionality you
have now with pcscd.
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.
I cam not a Trusted Extensions expert. I know that it evolved out of
Trusted Solaris 8, but now has permanent hooks in the kernel which are
enabled fully when additonal packages are installed. One of the goals
of that project was/is to make administration as painless as possible.
My understanding is it is far easier to configure than SELINUX, because
it doesn't require special compilers, and extremely rigorous detailed
and tedius analysis to establish and enforce airtight security.
But let's face it, no *highly* secure highly-capable computing environment
is pain free or free of administration hassles and overhead. Not yet
anyway. There is always a price to be paid for security, and it is
generally an issue of trade offs.
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.
OK, but I think there are too many interleaving threads
to to clearly determine what is really being addressed by
some of the scenarios you've introduced. All I want to
determine is whether you've got a solid indictment of a
particular proposed pcsc-lite change.
When you try to support your contentions with hypothesis such
as 'what if someone hacks into the system...', it goes out of
scope and derails the argument, because at that case, all
bets are off anyway. So why waste time on it?
The main issues I'm concerned about on this list pertain directly
to how we can make reasonable extensions that enhance pcscd to be
suitable for our project's needs and can be usefully leveraged
by the open source community. We don't want to introduce any
regressions or introduce any platform dependencies.
I'd rather that you present a clearcut argument focused on a
specific architectural change to pcced. demonstrating why some
specific area is clearly not viable by using the most focused
relevant example(s) possible.
For example, I think many of the security nuances of our particular
application are out outside of the scope the salient topic of
pcsc-lite, but were just presented to put things into context.
I don't want to rat hole forever on our particular application.
Paul
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
