On Tue, Dec 28, 2010 at 11:58 AM, Philip Prindeville
<philipp_subx_at_redfish-solutions.com> 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.
Received on 2010-12-28 18:12:24 CET