Questions about PAM, GDM and gnome-screensaver




Ray:

Thanks for your comments.  I am cc:ing Gary Winiger, who is the PAM
expert here at Sun.  I hope that he can chime in and help to answer
some questions about Solaris PAM where I might not know the details.

The main difference in how GDM and
gnome-screensaver interact with PAM is mainly with auditing.

So gnome-screensaver and GDM conceptually do different things with PAM
(even if a lot of the code is similiar looking).
>
GDM has to do 3 separate things:

1) find out who's trying to login (which usually means asking them,
and then making them prove it).
2) find out if the person who's trying to login is authorized to do so.
3) log the user in

gnome-screensaver has to do something entirely different and
conceptually a lot simpler:

1) make the person trying to unlock the screen prove that they are the
person who logged in initially.
2) refresh any credentials that timeout

I understand.  I was just trying to get a feeling if there is any plan
to make the two programs share a common PAM interface.  While the two
programs are doing different things, it might still be possible to
take care of PAM in one place.  But, perhaps it doesn't make sense.  I
was just asking.

So, I don't think the desire to support interacting with PAM modules as
root (or with privilege) is really a Sun-specific thing.
It's not a Sun specific thing.  It comes up quite frequently in fact.

Overall, you seem to be suggesting that Solaris should be using the
Linux model of allowing users to authenticate themselves via PAM.  On
Solaris we currently require that PAM conversations are done by a
user/roll with higher privilege.

In the past Gary has explained to me that the Linux PAM model does not
make sense on Solaris.  I suspect this might have to do with the fact
that Solaris supports things like Trusted Solaris, which has more strict
rules about how privilege is managed.  I am hoping Gary can explain a
bit more in detail and help answer your questions.

There are lots and lots of pam modules out there.  Quite frequently, a
pam module needs to do something that requires special privileges
(open /etc/shadow, or read a fingerprint scanner, or whatever).
That's okay and expected, but code that requires special privileges
needs to be smart about how it uses those privileges.  Privileges come
with responsibility.  We don't want to run a bunch of code in the
user's session as root.  It's not smart.  It's not secure.  We need to
minimize the code that's run as root, and more generally only give
privileges where needed.

I do agree that you need to be careful about how privilege is managed in
PAM modules.  On Solaris we use different mechanisms to manage
privilege than on Linux.  For example, Solaris uses RBAC and supports
Least Privilege to help manage these things:

  http://en.wikipedia.org/wiki/Role-Based_Access_Control
  http://www.sun.com/bigadmin/features/articles/least_privilege.html

For user session unlock, the default shouldn't be "run all pam modules
as root".  What I mean is, if a pam module needs root privileges to
look at /etc/shadow to confirm a password hash matches, that doesn't
mean the entire pam module should run as root!  It should only run as
root long enough to open /etc/shadow.  Furthermore, pam modules that
don't need root shouldn't get root.

When using Solaris, these things should probably be managed by following
least privilege.

 And like I said before, there are lots and lots of pam modules.
gnome-screensaver has no idea what modules its running when it
initiates a pam conversation.  It can't know which modules it's
running will need root, which ones will need acl access to some device
file, and which ones just need access to the network, or the users
session.

Only the individual modules know that.  It's each modules own job to
figure out what things it needs access to, and its each modules own
job to gain that access on its own.  If a pam module needs to access
something as root, it should have a carefully written, small setuid
helper program that opens the resource and drops privileges.  Also, if
you've got something like SELinux, then you should be able to label
the helper to only get access to the resources its supposed to get
access to.  Also the helper should be very restrictive about what it
checks.  If the real uid it's running as is user foo's, then it should
only check secrets that belong to user foo.

Obviously we don't have SELinux on Solaris.  Instead we use least
privilege and RBAC.

I don't think setuid/setgid is the best approach for granting privilege
when using RBAC and the least privilege model.  I know that Sun makes
a lot of effort to avoid setuid/setgid scripts because this shouldn't
be so necessary when using roles and least privilege properly.

Running the entire pam conversation as root is just not responsible or secure.

Any pam module that expects to be run as root is either not designed
to work from within a users session (i.e. is designed for login
programs, but not unlock programs) or is broken.

Perhaps this is true on some operating systems, and in some PAM
configurations; but I think these things are hard to assert as always
being true.

In short, I think if we want to make gnome-screensaver work on Solaris
we probably should start by making it possible for it to work with
the PAM interaction handled by a separate root-owned daemon and to
add SunAudit logic.  Does this seem reasonable?
>
The PAM interaction needs to run within the session, because things
like keberos tickets get renewed when the user unlocks the
screensaver.

Is this always true, or just true with some PAM kerberos
implementations?  I know Sun has kerberos modules.  While I haven't
personally used them, and cannot vouch that they work; I haven't
heard about such problems using kerberos PAM modules on Solaris.
I'm guessing PAM is just managed differently on Solaris than on Linux.
Perhaps Gary can clarify?

At any rate, if a user or distro wants to run the entire PAM stack as
a user or role with privilege, it seems that it would be nice if
gnome-screensaver allowed you to configure itself to work this way.

I will take up this issue again with our PAM team and see if they might
be more open to the idea of allowing PAM to authenticate users without
needing to run PAM with privilege.  In the past, they have said this is
a bad idea for the Solaris model.  I will need to discuss further with
them to get the specific reasons, or perhaps Gary can chime in.

If we can document the specific reasons why we need PAM to run with
privilege (as a user/role with more privilege than the user), and if
these reasons are valid in a Solaris context, then would the
gnome-screensaver project be willing to entertain a patch that would
allow us to build gnome-screensaver this way?

I'm not suggesting we should change how things work on Linux, I'm
just trying to see if gnome-screensaver can be configured to work on
Solaris.  I think people here at Sun would be happy to provide
patches for review if the gnome-screensaver project agrees that this
is worth the time.

Right now, we are using a hacked xscreensaver to meet our lock screen
needs on Solaris.  Within the Sun GNOME team, we would like to better
follow the GNOME community and use gnome-screensaver instead if we can
work together.

Brian



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]