Re: PAM authentication patch - v2

Brian Murphy <[email protected]> writes:

> Despite the dire warnings in the PAM documentation I can't see that
> using program_name is a problem.

Agreed, program_name as a default service name is not a horrible idea as
the program_name will likely be controlled by the system administrator
of the system that owns the cvs repository.

If you are going to the trouble of using PAM authentication, then the
administrator should more easily be able to specify what his PAM config
is setup to use. This should probably either be via an argument to
configure (I don't really like this one as multiple administrative
domains may want to use the same cvs executable) or via a CVSROOT/config
option in the repository.

> CVS is not installed suid root so it has no special priviledges unless
> it is run as root and you need to be root to do that. If cvs should
> ever become a daemon and run suid then this could be a problem.

You may need to consider the folks that have enabled the SETXID_SUPPORT
option when building their cvs executables. I have not looked at that
code in some time, but if you choose to add PAM support, you must also
consider these kinds of odd configurations and how they impact your
security model.

> The service name determines the configuration file that gets user for
> PAM. If you are a local user already then even an unrestricted cvs
> cannot do more than you as a user can. And you still cannot change
> what the cvs accessed via pserver is called.

...unless you can somehow find a way to have cvs elevate your privilege
level for you... possibly due to odd configuration or installation
choices on the part of the admin installing cvs.

> Can anyone else see the problems I'm missing?
> 
> /Brian

There has been some discussion of PAM service names on the
openssh-unix-dev list. There was a big stink about "ssh" as used by
a debian patch and "sshd" as used by other folks.

Granted this is using a long running root daemon, but it would seem
to be a parallel to the :pserver: method and learning from those who
have been thru this particular nightmare may be useful.

You see, there has also been a fair amount of pain in how PAM was being
used across various systems where the semantics of the function calls
were not consistent on various operating systems. In fact, I am not sure
if they have sorted out all of the variations as yet.

It may be useful to visit the archive of e-mail 
  http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

I believe the most recent thread has a subject like

  Changing PAM service name in sshd_config

As I noted above, it may be reasonable to consider using program_name as
the default, but to add a new CVSROOT/config keyword for the PAM
service_name in case there is a reason for local administrators to set
things up in one place that is known to operate correctly.

It may also be possible to look at the PAM code in openssh 3.6p1 and see
how they are doing things in a 'portable' manner to a number of
different systems.

All that said, I am concerned that addin PAM support is likley to be
more trouble than it is worth.

For myself, I find I share Greg A. Woods opinions that CVS is not a
security application and should not be looking at any password.

I am pragmatic enough to not be willing to yank :pserver: mode which
should only be used in a secure intranet. Cleaning up problems in the
password code the pserver path takes is a fine idea.

The idea that someone might be having a trivially hashed copy of their
real login password stored into ~/.cvspass strikes me as an extremely
bad idea. If a user only gets their 'cvs password' compromised it is not
necessarily as bad as losing the 'login password' used for other purposes
on their network.

Folks will do what they will do, but I would rather NOT see anyone say
that using PAM is somehow more secure than hacking CVSROOT/passwd
because it is not. It retains the vulnerability to the ~/.cvspass file
and potentially exposes a more interesting shared secret over the wire
in the clear.

	Just my $0.02,
	-- Mark