[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Linux security issues as they pertain to CVS

From: Greg A. Woods
Subject: RE: Linux security issues as they pertain to CVS
Date: Tue, 29 May 2001 16:30:34 -0400 (EDT)

[ On Tuesday, May 29, 2001 at 09:18:33 (-0500), Thornley, David wrote: ]
> Subject: RE: Linux security issues as they pertain to CVS
> Any problems with running pserver over an encrypted channel?  It seems to
> met that would be just as secure as ssh access (and, of course, just as
> unsafe - the biggest potential security problems being the guys on both
> ends of the channel).

That more or less defeats the purpose since you usually have to have a
real identity to establish a secure channel connection to a server in
the first place so why not just use that channel for remote job
execution?  (unless you're talking about an IPsec VPN tunnel, but then
you've got different issues to worry about)

With something like SSH the server host must implicitly trust the client
host (which is why it has to establish the identity of the client host),
and the user must implicitly trust both his client and the server --
i.e. every bit of hardware and software between the tips of his fingers
and the magnetic domains on the surface of the server's disks.

The trick is that the owner of the hardware, and the other bits on the
same disk(s) has to trust the user too, and that's where things get fun.

If you've got an end-to-end IPsec tunnel between the CVS server and the
CVS client machine(s) then as a CVS administrator you are probably
literally better off to use rsh and to transfer your trust to the client
computer (i.e. assume that when it says the user "joe" calling then it
is indeed the same user "joe" you would have authorise access to if you
had authenticated him, and that the remote client has itself
authenticated the person at the keyboard and determined him to be "joe")
since in many ways you've implicitly done that already by accepting the
IPsec tunnelled packets in the first place

CVS pserver on the other hand is under the full and direct control of
the (or rather *any*) user at the other end so you cannot transfer your
trust to the client CVS program and you cannot be sure that the person
at the remote keyboard really is the same "joe" -- there's no secure
link between the authentication done by the remote client computer to
allow that user to access it and whatever might be claimed over the
pserver channel.  Therefore pserver even over a secure channel is not
itself secure.

Proper use and understanding of SSH teaches administrators where they've
really placed their trust.  They would be wise to learn from it.

This is even more critially important when the remote client is itself
running on an insecure platform.  If you cannot trust that client system
to run SSH then you most certainly cannot trust it with anything else.
(and that's where intrusion detection becomes important, eg. why
employees are often required to wear photo-ID badges in larger

Encryption alone does not give you "security".  Security has four
tightly coupled parts:  Authentication, Authorisation, Integrity,
Privacy; and you cannot call something secure if you take away one of
those components or if you mis-use any one in such a way that you've
disconnected it from the others.

                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]