Mahmood:
>> Unfortunately this was never well documented in any PAM documentation
>> so I can easily understand how the setuid helper for authentication
>> was implemented.
>>
> I believe the issue is in the evolution of GUI libraries (specially
> libgtk) whereas PAM stuff was designed for more of a text based
> authentication. PAM to me seems primarily as a concept of doing
> authentication, and it uses delegation, i.e. delegate the authentication
> to pluggable modules. Or you could say outsource authentication to
> modules :-)
I don't really understand your point, Mahmood.
Since PAM needs to run with authority, and you typically want a GUI
program to run as root, then it seems to make sense to split the
GUI and the PAM conversation code into two processes. In fact,
this is done with both GDM and screensaver.
The GUI simply runs as a separate process with lower privilege
and talks to a backend process which actually talks to PAM.
> Now, since you are outsourcing, and dont provide your own GUI lib,
> people went ahead and outsourced the setuid limitation, so they could
> use libgtk.
In general, I think it is a good idea to avoid running GUI programs
as root. So even without the setuid limitation, it seems that
splitting the GUI and PAM code into separate processes makes good
sense.
> We at Sun, either have to provide a secure libgtk (which can be run with
> root privs), or fill in the holes present in setuid helper programs. I
> am not sure there is a third option. Or is there?( current xscreensaver
> is a dead end)
>
> Guaranteeing that libgtk is safe to be used by root with all the
> extensions that keep getting added to it and perhaps could be loaded at
> run time is not possible. Perhaps we could just make a subset of libgtk
> that only does what we need in gnome-screensaver and accessibility libs
> of libgtk. This still would be a big mess but perhaps dooable.
As you point out, trying to make GTK (and probably any GUI widget set)
appropriate for running as root is probably not worth the effort.
> What exactly is broken in the setuid helper programs that red hat
> currently uses. I have tried to understand the shortcomings of helper
> program but never quite understood its limitations. If you guys point me
> to exactly what is broken, perhaps we try to fix the broken parts?
To be fair to Linux, I am not sure anything is "broken". It is probably
more accurate to say that Solaris and Linux are following different
security models, and use different tools to support their models.
Anyway, to answer you question, the Linux approach is to modify the
PAM modules to use setuid/setgid programs (and similar techniques) to
do whatever might be needed that requires authorization. This way PAM
can run as the user.
Some Linux people say that this approach is better because it follows
"least privilege" principles, only providing authority to code that
needs it rather than running the whole PAM stack as root.
However, on Solaris we have more sophisticated "least privilege"
technologies that allow us to easily run PAM modules as root and
drop privileges that are not needed. Also, it probably is more work
(and more bug prone) to hack every PAM module that needs privilege
than it is just to simply run PAM with privilege in the first place.
You ask for people to point you towards the "broken parts" so that
we can fix them. It would be a significant (and probably impossible)
amount of work to convince either the Linux or Solaris communities
to change the security models they are using.
Instead, the only practical solution is to just simply make sure that
the screensavers can be configured to work with either security
model.
In other words, on Linux, it is okay to interact with PAM as the
user. On Solaris, it is necessary to have a helper program
running as root to talk to PAM. Making it possible to configure
a screensaver to work either way seems like less work than has
already been spent talking about this.
----
A more interesting issue, in my opinion, has to deal with the
fact that it is obviously necessary for the screensaver to run
with the user's Xauth permissions. So it is very easy for any
other program running as the user to snoop the password being
entered into the screensaver using a technique like Xspy:
http://www.acm.vt.edu/~jmaxwell/programs/xspy/xspy.html
I believe this violates the following Trusted Path requirement:
N.B. part of trusted path is that it must not be possible for
any program to interpose on or impersonate the trusted
path. Thus no program, nefarious or not, may view or
modify trusted path communication.
Using GrabServer in the lock screen program would fix this, but this
is not a good option since that causes problems for programs that want
to continue to draw things to the Xserver (such as if you have a Firefox
Flash video playing behind the lockscreen)
Perhaps the Xserver security extension is a good option, but none
of the screensavers on Solaris currently use this, or deal with the
this problem in any way.
When I talked with the gnome-screensaver maintainer about making
changes to gnome-screensaver to fix the "Trusted Path" related PAM
issues we discuss above, his remark was (paraphrase) "why is Sun
so worried about trusted path in the PAM stack, when you have this
gaping hole with Xauth?"
Brian
