Re: svnadmin create and not being method agnostic
Guten Tag Philip Prindeville, am Montag, 27. Dezember 2010 um 22:28 schrieben Sie: > In our case, we're setting up a secured source repository inside > our network, for outside access (via port-forwarding on our gateway). In this scenario and if security is this important for you, then why not just use svnserve? Depending on how extern suers should access, of course. svnserve can be bound to it's specific address and port which is much easier to configure on gateways and firewalls, tunnel through SSH and all that stuff. Each repository gets it's own physical configuration per default and you don't need to combine Apache and svn configuration in any way, which is error prone in my opinion. At least you wouldn't need to worry about unused configuration files or even worse, unused code in the built software. :-) We for example use SSH for gateway authentication, let the SSH users for repository access just talk to one IP and port where a dedicated svnserve is hosted just for extern access on it's own repositories. This svnserve instance can't see our code repositories, because of it's own user and root path, and each of it's repositories has it's own user and authz access configuration. Results in encrypted traffic, Subversion and Apache can be updated independently and easier and distinguished configuration. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: svnadmin create and not being method agnostic
On Mon, Dec 27, 2010 at 01:28:34PM -0800, Philip Prindeville wrote: > On 12/27/10 11:34 AM, Ryan Schmidt wrote: > >On Dec 24, 2010, at 23:34, Philip Prindeville wrote: > > > >>Unfortunately, the documentation and utilities in a few places are less > >>clear than they could be when discussing repository setup for svnserve > >>versus svnserve+ssh versus apache. > >> > >>For instance, "svnadmin create" deposits various files there: > >> > >>conf/svnserve.conf > >>conf/passwd > >> > >>which are useful for svnserve... but not for Apache access. > >So if you're not using svnserve, just ignore those files. > > We'd rather not have files laying around not serving a purpose... > especially if in some future version they start being meaningful again > and their contents implicitly grant some sort of access. The configuration files won't suddently change their purpose in a future version of Subversion (maybe in 2.0, but not before). > When securing a machine, you start by closing everything up, and then > opening up just what you need to accomplish the mission. "Closing > everything up" in this context would include removing unused > configuration files. I don't understand why unused configuration files would be a security risk. The important bit about security is that admins understand how to configure the application they're setting up. They can then configure it securely. I suppose your real concern is that you or others would get distracted by those files. Which implies a lack of understanding about how the system is or has been configured. I'd say the real problem here is documenting your setup properly and making sure everyone involved knows what this documentation says. > In short, ignoring the files isn't an option. Many UNIX-like operating systems come with configuration files in /etc for applications that aren't being run unless the user enables them. People ignore those files all the time. In any case, you're free to simply remove configuration files that "svnadmin create" creates. But I don't see a point in adding an option for this because it doesn't seem to be a very common need. Stefan
Re: svnadmin create and not being method agnostic
On 12/28/10 3:44 AM, Stefan Sperling wrote: On Mon, Dec 27, 2010 at 01:28:34PM -0800, Philip Prindeville wrote: On 12/27/10 11:34 AM, Ryan Schmidt wrote: On Dec 24, 2010, at 23:34, Philip Prindeville wrote: Unfortunately, the documentation and utilities in a few places are less clear than they could be when discussing repository setup for svnserve versus svnserve+ssh versus apache. For instance, "svnadmin create" deposits various files there: conf/svnserve.conf conf/passwd which are useful for svnserve... but not for Apache access. So if you're not using svnserve, just ignore those files. We'd rather not have files laying around not serving a purpose... especially if in some future version they start being meaningful again and their contents implicitly grant some sort of access. The configuration files won't suddently change their purpose in a future version of Subversion (maybe in 2.0, but not before). When securing a machine, you start by closing everything up, and then opening up just what you need to accomplish the mission. "Closing everything up" in this context would include removing unused configuration files. I don't understand why unused configuration files would be a security risk. The important bit about security is that admins understand how to configure the application they're setting up. They can then configure it securely. I suppose your real concern is that you or others would get distracted by those files. Which implies a lack of understanding about how the system is or has been configured. I'd say the real problem here is documenting your setup properly and making sure everyone involved knows what this documentation says. If I know that they're used only by svnserve and I'm never going to use svnserve, maybe I don't want they lying around just to svnserve will never be run (by a hacker for an exploit). That seems pretty straigthtforward. In short, ignoring the files isn't an option. Many UNIX-like operating systems come with configuration files in /etc for applications that aren't being run unless the user enables them. People ignore those files all the time. Rarely are they for network services. In any case, you're free to simply remove configuration files that "svnadmin create" creates. But I don't see a point in adding an option for this because it doesn't seem to be a very common need. Stefan
Re: svnadmin create and not being method agnostic
On Tue, Dec 28, 2010 at 08:58:43AM -0800, Philip Prindeville wrote: > On 12/28/10 3:44 AM, Stefan Sperling wrote: > >The important bit about security is that admins understand how to configure > >the application they're setting up. They can then configure it securely. > >I suppose your real concern is that you or others would get distracted > >by those files. Which implies a lack of understanding about how the > >system is or has been configured. I'd say the real problem here is > >documenting your setup properly and making sure everyone involved knows > >what this documentation says. > > If I know that they're used only by svnserve and I'm never going to use > svnserve, maybe I don't want they lying around just to svnserve will never be > run (by a hacker for an exploit). > > That seems pretty straigthtforward. But svnserve will run even if the svnserve.conf file doesn't exist. Stefan
Re: svnadmin create and not being method agnostic
On Tue, Dec 28, 2010 at 11:58 AM, Philip Prindeville wrote: > On 12/28/10 3:44 AM, Stefan Sperling wrote: >> >> On Mon, Dec 27, 2010 at 01:28:34PM -0800, Philip Prindeville wrote: >>> >>> On 12/27/10 11:34 AM, Ryan Schmidt wrote: On Dec 24, 2010, at 23:34, Philip Prindeville wrote: > Unfortunately, the documentation and utilities in a few places are less > clear than they could be when discussing repository setup for svnserve > versus svnserve+ssh versus apache. > > For instance, "svnadmin create" deposits various files there: > > conf/svnserve.conf > conf/passwd > > which are useful for svnserve... but not for Apache access. So if you're not using svnserve, just ignore those files. >>> >>> We'd rather not have files laying around not serving a purpose... >>> especially if in some future version they start being meaningful again >>> and their contents implicitly grant some sort of access. >> >> The configuration files won't suddently change their purpose in a >> future version of Subversion (maybe in 2.0, but not before). >> >>> When securing a machine, you start by closing everything up, and then >>> opening up just what you need to accomplish the mission. "Closing >>> everything up" in this context would include removing unused >>> configuration files. >> >> I don't understand why unused configuration files would be a security >> risk. >> >> The important bit about security is that admins understand how to >> configure >> the application they're setting up. They can then configure it securely. >> I suppose your real concern is that you or others would get distracted >> by those files. Which implies a lack of understanding about how the >> system is or has been configured. I'd say the real problem here is >> documenting your setup properly and making sure everyone involved knows >> what this documentation says. > > If I know that they're used only by svnserve and I'm never going to use > svnserve, maybe I don't want they lying around just to svnserve will never > be run (by a hacker for an exploit). > > That seems pretty straigthtforward. Disabled entirely would be better, and safer, than empty. Subversion's security models have historically been very lax. This is inherited from its origins in CVS, and the attitude that "if you don't trust your machine, you shouldn't be using it!!!". It's also played out in the historically clear-text storage of user passwords for HTTP and HTTPS access in $HOME/.subversion/. That feature needs not merely to issue a client warning, and it remains a compelling reason to use svn+ssh, despite the lack of a graceful key management tool for Subversion. (Yes, I've sung this song before.) It's an underlying security model problem. Subversion security remains an after-thought to its design, with the result of admin's having to create their own security models on the fly rather than it being integral to the software. >>> In short, ignoring the files isn't an option. >> >> Many UNIX-like operating systems come with configuration files in /etc >> for applications that aren't being run unless the user enables them. >> People ignore those files all the time. > > Rarely are they for network services. Well, this is not exactly true. For RHEL and the like, /etc/httpd is often populated by verious services that require manual activation, as is /etc/xinetd.d/. MRTG, Bugzilla, ViewVC, and Nagios all come with configurations that are inactive by default. Dont' get me *started* on Trac (Trac and ViewVC are particularly relevant to Subversion managers.) >> In any case, you're free to simply remove configuration files that >> "svnadmin create" creates. But I don't see a point in adding an >> option for this because it doesn't seem to be a very common need. >> >> Stefan Keeping them entirely disabled in an svnserve.conf file would be more sensible. As Stefan pointes out elsewhere, svnserve will run without an svnserve.conf. Perhaps it *shouldn't*, and the default svnserve.conf should be published as svnserve.conf.tmpl? That would force manual enabling of a service that should not be available by default.
Re: svnadmin create and not being method agnostic
On Tue, Dec 28, 2010 at 12:11:47PM -0500, Nico Kadel-Garcia wrote: > As Stefan pointes out elsewhere, svnserve will run without an > svnserve.conf. Perhaps it *shouldn't*, and the default svnserve.conf > should be published as svnserve.conf.tmpl? That would force manual > enabling of a service that should not be available by default. svnserve reads the repository's svnserve.conf file when it receives a client request concerning this repository. In other words, there is nothing we can do in the repository-specific svnserve.conf file to prevent svnserve from starting in the first place. Also, I don't understand how starting svnserve would help an attacker since to start svnserve the attacker would already need access to the system. Users with shell access to the system can of course run their own svnserve instance on an unprivileged port (and svnserve runs on an unprivileged port by default). There is no way to prevent this. The user might even copy an svnserve binary from a remote system and run it. But the same is true for any other network daemon that can be run on an unprivileged port. Stefan
Re: svnadmin create and not being method agnostic
On 12/28/10 11:11 AM, Nico Kadel-Garcia wrote: Disabled entirely would be better, and safer, than empty. Subversion's security models have historically been very lax. This is inherited from its origins in CVS, and the attitude that "if you don't trust your machine, you shouldn't be using it!!!". It's not exactly CVS's fault - it is extremely rare for any application to manage it's own security at the level you want and unheard of for one that is portable across platforms. And when they try, people complain that it isn't integrated with the OS and is yet another password to write down or forget. -- Les Mikesell lesmikes...@gmail.com
Re: svnadmin create and not being method agnostic
On Tue, Dec 28, 2010 at 1:28 PM, Les Mikesell wrote: > On 12/28/10 11:11 AM, Nico Kadel-Garcia wrote: >> >> Disabled entirely would be better, and safer, than empty. Subversion's >> security models have historically been very lax. This is inherited >> from its origins in CVS, and the attitude that "if you don't trust >> your machine, you shouldn't be using it!!!". > > It's not exactly CVS's fault - it is extremely rare for any application to > manage it's own security at the level you want and unheard of for one that > is portable across platforms. And when they try, people complain that it > isn't integrated with the OS and is yet another password to write down or > forget. CVS was written when the encryption resources were less available in terms of system resources and in terms of US encryption export regulations, and when the 24x7 connection we have now for central software repositories was quite unusual. So historically, it's unsurprising. It evolved over time into Internet wide repository access, when the clients were far fewer and online access was much more rare. Subversion was written much later. Continuing the security policies of CVS seems unwise, and you've seen me grouse about it before (and make some suggestions, and it's admittedly gotten better). But better client and server access control is also hardly "unheard of". Plenty of more modern tools take client and server security far more seriously, including cross-platform source control tools. Bitkeeper, git, Perforce, and mercurial all leap to mind as cross-platform source control tools that do a better job of this particular aspect. The only system I've seen in broad use with such poor security commonplace is CVS, and I've helped several companies from CVS to Subversion to get them doing *something* better than CVS. (I also helped set their guidelines for repository management and insistence on svn+ssh based access.) Password handling is a distinct issue than turning off, and *keeping* off, unnecessary access methods for a specific repository. Disabling unnecessary access by default is a basic security procedure, and would help protect new Subversion administrators from surprises.
Re: svnadmin create and not being method agnostic
On 12/28/10 1:57 PM, Nico Kadel-Garcia wrote: But better client and server access control is also hardly "unheard of". Plenty of more modern tools take client and server security far more seriously, including cross-platform source control tools. Bitkeeper, git, Perforce, and mercurial all leap to mind as cross-platform source control tools that do a better job of this particular aspect. So is there a cross-platform library suitable for general-purpose use? -- Les Mikesell lesmikes...@gmail.com
Re: svnadmin create and not being method agnostic
2010/12/28 Thorsten Schöning > Guten Tag Philip Prindeville, > am Montag, 27. Dezember 2010 um 22:28 schrieben Sie: > > > In our case, we're setting up a secured source repository inside > > our network, for outside access (via port-forwarding on our gateway). > > In this scenario and if security is this important for you, then why > not just use svnserve? I don't know what Philip's reasons are, but svnserve does have some shortcomings that might make it unsuitable for sites that are serious about security. The most obvious one is that it requires passwords to be stored in cleartext in the repository passwd file on the server. Another one is its lack of any logging or auditing capabilities. On the other hand, when you start using Apache you've got a whole 'nother pile of code that can have security holes in it...so it's really a matter of which risk you're more concerned about. -- David Brodbeck System Administrator, Linguistics University of Washington
