On Apr 12, 2007, at 16:46, Bruce Wilson wrote:
> Thanks for the speedy reply, Ryan. I think maybe I skimmed too
> quick over some of my points.
My apologies for my too-speedy reply; now I see what you mean:
> Ryan Schmidt wrote:
>
>> On Apr 11, 2007, at 22:14, Bruce Wilson wrote:
>>
>>> * WebDAV should not be available to the bugzilla sites.
>>> Subversion instance should not have access to modules specific to
>>> Bugzilla.
>
> By this I mean that I would prefer the Bugzilla sites be using an
> instance of Apache which does not even have the WebDAV module
> loaded. I know I can enable WebDAV on a site-by-site basis, but
> I'd rather not have it accessible to Bugzilla at all. I'm going
> for the "less is more" configuration for each instance, to make
> each site's config as simple as possible, to minimize the attack
> surface of each site, and to make sure that (for example) dav can't
> be leveraged against Bugzilla to get to my Postgresql server and
> parlay that into full control of my box.
I do see what you mean. But since you can configure DAV to be enabled
or not on a per-vhost basis, the only protection the above seems to
afford you is protection against bugs in the WebDAV module itself
that would manifest themselves on the server as a whole regardless of
its configuration. Granted, that may be a reasonable precaution. But
if it were my server, I probably wouldn't be very concerned about it,
especially if I kept my software up to date. I have a high degree of
confidence in the security of Apache and its included modules, and
the responsibility of its developers to release timely security
updates as needs arise.
>>> * The Bugzilla sites should not have file permissions to the
>>> Subversion repository.
>
> Subversion requires Apache to have write access to the repository
> directory. Bugzilla requires write access to several of its own
> directories. Since the two Bugzilla sites are public-facing,
> linked from multiple places and potentially turning up in search
> engines, I'm uncomfortable having those sites running under a user
> who potentially has access to the Subversion repository, holding
> private and proprietary data. The only way I've seen to control
> this is to run one instance of Apache as one user (perhaps "www-
> bugzilla") and another instance as another user ("www-svn"), so I
> can assign different permissions to each user.
I think you have a point here. I can think of no way to restrict the
Bugzilla installation so that it cannot access the files of your
Subversion repository, short of running two Apaches under two
different users as you suggest.
You'd be protecting against theoretical bugs in Bugzilla that would
enable an attacker to read any file the web server can read. But bugs
like that certainly have surfaced in other popular web-based
projects, so this concern is certainly not unfounded.
>>> * Configurations should not "bleed over" from one site to the
>>> other. That is, if I grant/deny a permission on a path in the
>>> bugzilla site, and that same path exists in Subversion, the
>>> permissions should not carry over.
>
> This may be more a case of my discomfort with Apache
> configurations. Reading all the Apache examples and config files,
> it's not at all clear to me how I can be sure that...
> <Location />
> Dav svn
> </Location>
> ...would not enable Dav for the root of all sites at once.
If you place that directive outside of any <VirtualHost> directives,
it will apply to all virtual hosts. If you place the directive inside
a <VirtualHost> directive, it applies only to that virtual host. This
is at least an easy question to answer. :) Um... well, except that
any modules you need for a particular vhost will have to be activated
for all vhosts. So as you noticed above, mod_dav and mod_dav_svn will
be loaded in memory, even for those workers that are only serving
Bugzilla requests.
Note too though that granting access to specific paths of a virtual
host (for a normal web site like Bugzilla, with <Location>
directives) is a different beast from allowing access to specific
paths of a Subversion repository (which is usually handled with
Subversion access files).
> From your reply, I guess I just need to get more familiar with
> nesting directives. Overall, I'm just having trouble putting it
> all together. Between my O'Reilly books on Apache and Subversion,
> reading the Apache .conf file examples, and the httpd docs on the
> web, I have seen lots of examples of how to do any specific X
> within either package - in isolation. I'm looking for a more
> detailed explanation of how to use certain features together.
>
> As you've probably seen, there's a bajillion websites (and forum
> posts and blog entries and columns...) that tell you how to switch
> Apache from single-site to vhost, but that's about as far as they
> go. They don't take it to the next step to show what a complex
> multi-vhost config looks like, with SSL, with DAV on limited
> directories, with mod-rewrites to force SSL, with custom access
> rules in specific paths, and so on and so forth.
>
> Of the places I've looked, the Subversion and Bugzilla install
> guides seem to have the most comprehensive explanations. Apache
> docs are often too general because they assume you'll know what
> options you'll need for your site.
I've managed several multi-purpose Apache servers for a web hosting
shop. It's not that bad. As long as you keep directives inside
<VirtualHost> containers, they will apply only to that vhost.
Originally I had all vhosts in a single vhosts.conf file which was
included from the main httpd.conf file. Then later I found that you
could have Apache automatically include all files in a given
directory, and I split each site into its own include file in a
vhosts directory. For sites that used both http and https (even where
the http site just redirected all URLs to the https site), I kept
both the http and https vhosts in the same configuration file because
I found that more intuitive.
Redirecting http traffic to https should be an isolated topic for
which you can find a guide somewhere. But... it should just be this:
<VirtualHost 192.168.0.2:80>
ServerName secure.example.com
RedirectMatch permanent ^/(.*)$ https://secure.example.com/$1
# that's all you need in the redirect vhost
</VirtualHost>
<VirtualHost 192.168.0.2:443>
ServerName secure.example.com
DocumentRoot /path/to/docroot
# whatever other directives you want for the ssl vhost
</VirtualHost>
Note that Subversion doesn't like redirects. If the secure vhost here
hosts a Subversion repository and you try to check out over http on
port 80, it will not work; you'll get a cryptic error message.
>> I've never heard of Apache's "profiles" feature. I don't see any
>> reason for you to run a second copy of Apache. Just use another
>> vhost for your Subversion repository(ies).
>
> Hmm, I guess this is a feature of the FreeBSD port of Apache. It
> permits such things as "apachectl start profile1" to start an
> instance with a specific set of configurations. "apachectl start"
> launches all known profiles. I've seen references in other
> projects to using an "apache-profile-like" configuration method, so
> I figured it was a pretty widely known feature.
>
> I'll follow up with the port maintainer to see if there's any help
> on this feature.
>
> As I explained above, I'm pretty sure I can't prevent the Bugzilla
> sites from having write access to Subversion under a single
> instance of Apache. If I have to run all the sites under one
> instance I will, but what I know of this feature seems like a
> perfect fit for the configuration I'm after.
That does sound useful. It may be part of standard Apache, I don't
know. I've just never looked for such functionality.
>> If all your vhosts use SSL, then you need a separate IP address
>> for each vhost. (More specifically, you need one IP for each SSL
>> vhost. If you have additional non-SSL vhosts, they can be name-
>> based and can share an SSL vhost's IP, or use their own IP, as you
>> wish.)
>
> Yeah, I understand how name-based vhosts work. All three sites use
> SSL, so I am forced to IP-based vhosts.
>
> I'm sure someone must have written something with a bit more depth
> than "You can host two sites! With the same IP! Without changing
> ports! Here's how!", I just haven't found it yet.
>
> If you think I'm better off asking on an Apache list, please let me
> know - I don't want to be an annoyance if this isn't the right
> place for this.
As long as your questions are "how do I configure Apache to host my
Subversion repository," this is a good place to ask. Things like
starting multiple Apache instances and mod_rewrite rules start to go
beyond what usually gets discussed here and you might have more luck
on an Apache-oriented forum or list.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 13 12:36:06 2007