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 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. Welllll maybe. But that
has nothing to do with the smartcard reader.
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?
I was in the wrong place. Sorry.
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?
If everything works normally, yes.
If during the login process (between the time XDM aborts the login X
server and the new X server gets started and initialized) the TCP port
identifing the X server gets taken by an unauthorized process then the X
server you are expecting to get doesn't exist and will not exist. The
dpy# given to pcscd is wrong.
But then it won't refer to a valid X server, so pcscd's PAM module
will fail it. The check in pcscd's PAM module is is only that
the client's UID is the correct owner of a valid Xdpy # at
the time of the check. If it is, we assume the client has legitimate
access.
If someone can hack in such that they assume the UID of root
or the UID another user, then there is a problem, but that problem is not
pcscd's responsibility to prevent against.
XDM cannot guarantee that chain under the current method of operation. XDM
itself does not control the X display, nor port 6000 (which for the
discussion is dpy#0). All XDM does is start a different process to try
to open the port. Once it is open, that other process controls the port.
XDM reports a failure when the X server cannot open the expected port
simply because the X server terminates with an error when it cannot
complete the initialization by listening to the port.
If XDM aborts the pcscd daemon when the X server fails, then the window
of opportunity is rather small. I would expect it to be less than 1
second. It might be larger, but that depends on how long it takes the
X server to determine the inability to operate and do an error exit.
The XDM I have tries again and again (if it is not related to the
graphics display, the video can blink at about 1-2 times per second).
Now if it had been designed slightly differently - as in XDM opening the
port, and then passing an open fileid to the X server process to use,
then there would be no opportunity to steal the display (the port should
also be in the reserved port range so users could not attempt to open it).
but it is too late to do that now...
The alternative I was offering has the PAM module open a domain socket
(via socketpair) to pcscd, and put the fileid in a known location or one
that is pointed to by an environment variable.
XDM would have that environemnt (it iinitializes it at least) and the
open fileid. The X server XDM tries to start would also have it (since
it is started after authorization) and if there is a failure, the X
server process terminates closing its inherited fileid.
If it successfully starts then XDM continues setting the users
credentials. As long as XDM doesn't close the pcscd socket it will
remain open. The Xsession started by XDM (I believe that is done by an
exec) will inherit the fileid to pcscd, and any environemnt variable
that may have been set to point to it.
After that, any process started by the session will also inherit that
fileid and environment variable.
Suppose the X server is being spoofed... The process that grabbed the
X port will NOT be able to access the inherited fileid since they are not
part of the process tree decending from XDM. Even if they are in the same
zone/container.
[snip]
I don't think X Server being spoofed is in the scope of our discussion.
People need to address the security of their environments to prevent
that. pcscd doesn't open up any new vulnerabilities for that. Further,
in Trusted Extensions, the X Server runs in the global zone, and there
is know known way in Hell that a process running in a local zone
can mess with it, period.
...
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?
Because one of the biggest cracks I've ever seen was done that way.
Once one remote system got penetrated, that system was used to access
credentials of a valid user, and then jumped to another server. That
second server is the topic (right now, for discussion, it would be the
server hosting the Sun Ray boxes). It has been accessed with valid
credentials, but by an unauthorized person.
We are talking about a single machine, which is a Sun Ray server.
Right now pcscd doesn't handle remote accesses, and we are not
adding that feature. In our application network access is
rigidly controlled well beyond traditional UNIX mechanisms,
accesses monitored and zones are isolated.
If I can prevent the users smartcard from being accessed without
the users knowlege, then I will. Right now, every remote use of
the smartcard makes too many assumptions about WHO, WHERE, and under
WHAT conditions that access is granted. In the case of the Sun Ray...
If the card is accessed from the host, is that access being done
by the user... or a crack comining in via some highjacked connection
to the server? An audit of the Sun Ray would show that the access
came from the server... now, just try to get an audit of a server
with 50 to 100 active users... Especially where the connection to
the server had valid credentials.
For instance - that discussion on ssh --- nothing on the users
system can verify that the access being requested (over an encrypted
channel) is proper. It cannot tell if the user intended the access...
or if the connection has been taken over because the user did an
ssh connection to a third host that was cracked.
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.
Hopefully, I did manage to get sufficiently focused above.
Sorry about taking so long.
Well, it is interesting, but I think there are still misconceptions
about what we are doing, and I still think that as long as pcscd
doesn't introduce new vulnerabilities or regressions to security
that preventing system hacks is the responsibility of the administrator
or other tools, and that what happens after the system is hacked is
generally chaos, pcscd or not.
And I cannot spend hour after hour on this with you, as I'm
trying to get my 'day' job done. I still don't understand what
the specific architectural regression or brokenness is in our
setup.
The only change to pcscd I can see is being able to use a specified
fileid for requests. The response to a request is to generate a new
socketpair, and pass one of them back to the users process. This
returned fileid is the one to use for pcscd operations.
Since I believe other premises leading up to the conclusion were
not based on a clear understanding of what we're doing, I'm not
convinced that pcscd needs to 'grow a pair', as it were, yet,
anyway.
As far as I can see, for clients this changes only the library function
that initiates the connection to the pcscd daemon.
The process that starts the pcscd daemon is responsible for setting uo
the fileid for inheritance, and setting the environment variable to
identify which fileid it is.
These should be very limited changes to pcscd and applications, with
the greatest portability possible. It would not be limited in application
to just the Solaris/Sun Ray environment.
I don't understand it well enough, and if you still feel you have
a valid case, based on my clarifications I'd really appreciate it
if you can distill it down to a more succinct presentation. As
it is, I might have to put this discussion on hold until I get
some more work on this done. Michael Bender might have some
thoughts, or if he agrees with your assessment, enlighten me
about this.
Paul
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
