Re: Questions about PAM, GDM and gnome-screensaver

[Brian Cameron <Brian Cameron Sun COM>]

Ray:

> > > 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.
>
> Right that makes sense.
>
> > 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.
> This is part I don't understand.  Isn't the initial mail about getting
> gnome-screensaver to run setuid root?
>
> I guess my main point is we should try to limit the scope of
> root-running code in the session to be as small as possible.
>
> I think we're debating over two possibilities (but tell me if I'm wrong):
>
> 1) run gnome-screensaver setuid root and implicitly trust all pam
> modules the user uses to drop the privileges they don't need, and have
> a policy tailored for them to give them least privileges and the right
> roles

On Solaris we currently use xscreensaver.  The way that we addressed
this issue for xscreensaver is to break it into two processes.

- A daemon that runs with privilege, which talks to PAM
- A GUI that runs as the user.

These two programs talk to each other via a socket, but this could be
done with any other mechanism such as D-Bus.  That's one reason why
I brought up the idea of GDM and gnome-screensaver possibly sharing
PAM implementation.  If there is some value in having PAM conversation
handled by a process with privilege, then it might be easier to have
one process handle this rather than one for GDM and one for
gnome-screensaver.  But either way is okay with me, really.

It is incorrect to say that the daemon running with privilege needs to
run as root.  It could run as any role or user with the appropriate
privileges needed to run the PAM stack.  If the user himself has enough
privileges to do what is needed, then this could be the same user,
though this would probably not be a common configuration.

In other words, using RBAC and least privilege, you have a lot of
flexibility about how you could configure this to work.  If
gnome-screensaver allowed this two-process model, then it would
be nice if you could easily configure what user/role would be used
for running the daemon which actually talks to PAM.

This daemon would use "least privileges" techniques in order to reduce
its privileges to what is needed for the PAM modules to work.  This
could vary depending on the PAM modules that are being used in any given
situation.  Also, the PAM modules themselves could use least privilege
to further drop privileges as needed.

> 2) for pam modules that require root privileges, have them explicitly
> run a helper app that is setuid root and trust that helper to drop
> privileges it doesn't need.

On Solaris, you would not need to necessarily use root.  You could
use setuid to gain access to any user or role which has privileges
needed.  This approach isn't favored by the Solaris security folks.
They tend to dislike using setuid/setgid to gain privilege.  It is
not as easily configurable as using roles.

> am I right?

Mostly, though you seem to confuse the idea of roles and root.  With
RBAC you can define roles which have needed permissions, then you can
run processes with that role, ensuring that it has only the privileges
it needs.  Least privilege can also be used to ensure that processes
drop privilege for things they don't need, to ensure that if the
processes is somehow exploited it can't do things it wasn't intended
to do.

> > 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.
>
> isn't the point of least privileges to only run with minimal
> privileges?  If you're running the entire stack with one role and one
> set of privileges then you're running code with higher privileges than
> you need to (since not all pam modules require the same set of
> privileges).   You want to run every module with the privileges that
> any module could ever need?  So pam_ldap has privileges to read
> /etc/shadow?  pam_motd has the same privileges as pam_mkhomedir?

The sysadmin knows what PAM modules they wish to use, and they can
set up roles that have the needed permissions.  Then processes which
need to talk to PAM can be run with these permissions.

> > 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.
>
> Gary, it'd be great if you could share your thoughts and a rationale
> for wanting the change.

I'll ping Gary privately and let him know that it would be helpful to
get his perspective on things.  He knows quite a lot about how PAM is
designed on Solaris.  I'm sure I'm missing things.

> > 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.
>
> I guess if you're already patching your screensaver, you might be able
> to drop privileges around the gtk_init call and restore from the saved
> user id.
> Or set your role at the top of the file then setuid(getuid()) before gtk_init.
> I wouldn't recommend doing either of those though.

I don't think that it would be acceptable to run the GUI program with
privilege.  In order to support xscreensaver on Solaris, we needed to
break it into two processes as described above.  I am fairly sure that
the security folks at Sun would require a similar approach with
gnome-screensaver.  I don't think it would be too crazy for
gnome-screensaver to support the ability to configure itself to work
this way if desired.

This would have the additional benefit for users who want to use
existing Linux PAM modules that don't work well with the "call PAM
as user" model, such as the LDAP example.  I understand some would
argue these are PAM bugs, but it would still be nice if people could
build or configure gnome-screensaver to work with this sort of
environments if desired, rather than making people wait until such
PAM bugs are fixed.

At any rate, I just wanted to explore these ideas a bit more in depth,
and try to get answers to questions that were raised in previous
discussions so that we can move forward with this, if possible.  As
I said, it would be nice if Solaris could start supporting
gnome-screensaver for people who want to use it and have a more
GNOME integrated desktop.

Brian