Re: PAM authentication patch - v2

[Brian Murphy]

Steve McIntyre wrote:

> On Tue, Jul 01, 2003 at 05:18:40PM +0200, Brian Murphy wrote:
>  
>
> > Steve McIntyre wrote:
> >
> >    
> >
> > > did in mine (most recent against 1.12.1 attached for reference). Just
> > > one point that worries me - you only hardcode the pam service name if
> > > specifically configured that way, otherwise you just use the
> > > program_name. This is very dangerous and is specifically warned
> > > against in the PAM documentation I've read. If a user can sym-link to
> > > your CVS binary and use another name (easily done), they then get the
> > > option of using whichever PAM config they want. That's a security hole
> > > waiting to happen!
> > >
> > >      
> > Not really (a security hole). That is as long as you don't suid/sgid
> > your cvs binary. If you do then you need to force the service name to
> > something.  If you don't then the only way of exploiting the security
> > hole is to be the root user and root can do anything anyway. The cvs
> > documentation explicitly states the use of CVS in suid mode is
> > unsupported and evil (perhaps I extrapolate a little ;-)). Hence no
> > problem.
> >    
>
> It depends a lot on local config, to be honest. It's not just
> setuid/setgid. With PAM people can configure the system to only allow
> access to CVS for certain users, yet still (for example) host a POP
>  
CVS relies on the native OS protection, if I can do it via CVS I can also do
it via local filesystem operations. A non suid/sgid cvs binary can never
give you access to more than you can do anyway as yourself as a local
user of the machine, capable of making symlinks. You can always compile
your own cvs binary which does not have the restrictions of the one in
/usr/bin.

> service or something else that gives access to more users than just
> those in the passwd file. By sym-linking the cvs binary to a new name
> (to match the POP server), suddenly people have access to CVS when
> they should not. It's a little convoluted, but still a possible
> hole. For my PAM support, I just hardcoded the service name to be
> "cvs"; do you have a reason to do differently? I'm curious... :-)
>
>  
The reason is to allow several pam configurations (dependant on the name
cvs is invoked as) allowing internal and external access for example.

/Brian