Re: PAM authentication patch - v2

[Mark D. Baushke]

Brian Murphy <brian@murphy.dk> writes:

> Mark D. Baushke wrote:
> 
> >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.
> >
> What does this do?

Deals with the situation where cvs is either a set-uid or set-gid
executable.

> >...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.
> >
> One can always make any program installed by root give anyone root
> access. You can't legislate for stupidity.

True.
 
> >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.
> >
> Had a look at this and it doesn't look like they have any serious problems.

Okay.
 
> >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.
> >
> Doesn't seem to be too nightmarish to me, just bugs and fixes like any
> software.

Possibly, but it took them four releases of OpenSSH to get most of the
PAM users working. It still does not work properly for all systems that
have a PAM implementation. Of course, a major point for ssh is that it
is giving the user an interactive shell while cvs is not doing that.
However, dealing with expired passwords is still an open problem...
 
> >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.
> >
> Looks like what I do, all very standard - the ssh code is much more complex
> though.

Okay.

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

Both the bug-cvs and info-cvs will likely get more support questions
regarding this new feature.
 
> >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.
> >

> Most people probably have a non-password protected private ssh key in
> their ~/.ssh directory too. The cvs passwords are stored so that only
> the user can read/write them.

Actually, I suspect you are mistaken in your assumptions. It is way too
easy to mount user volumes or NFS filesystems and access the dot files
in a user tree if you are on a LAN. Storing passwords or non-password
protected private ssh keys are always to be discouraged.

After all, if you are going to give them PAM credentials on your cvs
server, why not just let them rsh into the box and use the :ext: method
without risking any passwords at all?

I guess that I really do not understand why :pserver: needs to use PAM
authentication. I am not saying there is not a reason, I just have not
understood it.

        -- Mark