On Sat, 12 Jun 1999 12:21:22 -0400 (EDT)
Greg A Woods <[EMAIL PROTECTED]> wrote:
> [ On Friday, June 11, 1999 at 22:04:01 (-0700), [EMAIL PROTECTED]
> wrote: ]
>> It is not secure to the extent that CVS'es pserver is not secure.
> I think you're confusing the issues here. CVS' pserver access
> method has nothing to do with using SSH to access a CVS
> repository.
True. If you use SSH to gain shell access and then use normal
filesystem-level CVS commands to access the repository, there is no
net change in _system_ security. This is not true however for
accesses via pserver.
> With SSH (or RSH for that matter) CVS runs as the authenticated
> and authorised user and in that sense is totally secure (it can
> offer no means of changing or enhancing the user's privileges).
Not exactly true. You can (I've done it) use SSH to redirect the
pserver port on the repository machine over SSH to the client. In
qtruth, this was my automatic assumption about what was being
discussed.
In this case (port forwarding et al) pserver continues to execute as
root (it has to to be able to do the setuid()), and setuid()'s down
to the calling user upon access. The exposure remains that pserver
itself can be compromised thus releasing root access to your SSH'ed
accounts.
>> It is effectively tantamount to granting those users shell access
>> to the server with a reasonable probability that they may be able
>> to exploit that shell access into root access (given that pserver
>> runs as root and was not designed or built with security in
>> mind).
Which is the other side of pserver: that even if you do not provide
shell access to your system (ie there are no login shells on the
system), and you use pserver only for CVS, then you are *still*
effectively granting shell access to the system _and_ doing it via a
priviledged executable.
> You really shouldn't be running a CVS repository on any machine
> where you don't want the CVS users to have full shell access.
True. This is one of the reasons I don't recommend CVS for projects
without very tightly constrained memberships.
> You're sort of right: *CVS* was not designed with that *kind* of
> security in mind.
<nod>
>> > Is there a hole I don't see, or a better method available?
>>
>> As I mentioned previously, we're very happy with BitKeeper. Yes,
>> you're still granting shell access to the host containing the
>> source repositories, but you have the advantage that there are no
>> server daemons running as root or other proviledged users.
> Checking authentication and granting authorisation requires some
> sort of enhanced privilege. On unix there is truly only one level
> of enhanced privilege: superuser. SSH is a well accepted method
> of providing secure authorised access to a server.
<nod> This is also why pserver must run as root.
> Although I don't believe the CVS pserver daemon code has been
> subjected to quite as rigorous analysis as the SSH code has been,
> it is somewhat smaller and simpler (and thus possibly easier to
> analyse) and avoids the export issues of crypto code, so may be
> more suitable for some applications. Unfortunately it's
> implemented as an integrated part of the entire CVS server,
> something that certainly complicates the issue.
True. There have been many suggestions to abstract the
autenticationa and connection logic from pserver to then have it
hand off all operational functions to a non-priviledged executable.
It doesn't solve all the problems, introduces a few small new ones,
but there is a net gain.
> The one major advantage of pserver is that it allows minimal and
> simple authentication of "anonymous" users -- i.e. users who don't
> have shell accounts.
True, and is very analagous to AFTP in that sense.
> One could just as easily use a hacked version of sshd or even rshd
> to read a separate password file and to invoke only CVS. Neither
> of these methods are guaranteed to prevent someone from cracking
> shell access on the repository machine, due to the nature of CVS.
My concern is not shell access per say -- that is a well known and
documented area. My concern is using pserver under some sort of
illusion that it is secure. Authentication is all very well and
good but its not security: Great, you now know exactly who hacked
your system.
> I would always recommend running a truly anonymous CVS server on
> an isolated single-purpose machine that has a regularly updated
> copy of the main repository.
Yup. I usually (well, I used to) also run it in a chroot jail.
Fairly trivial to set up with Vietse's tools, and a modicum of added
security (oncre root is compromised even a chroot jail is not
secure).
--
J C Lawrence Internet: [EMAIL PROTECTED]
----------(*) Internet: [EMAIL PROTECTED]
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
