Hi, On 08.04.2012 21:58, Stefan Fritsch wrote: > The basic requirements are > A) allow access to /var/www > B) allow access to /usr/lib/cgi-bin > C) webapp packages will want to allow access to the directories which > they map with an alias, e.g. /usr/share/webappX/docs > D) deny acces to .ht* plus, possibly, some other sensitive files, e.g. ".svn", think of #548213 and whatever the equivalents of other version control systems are. Not to say we should do that, but we may keep that in mind. > Currently, this is done by simply allowing access to directory / (by > not specifying any restriction) and denying access to .ht*. There are > special rules to allow /var/www and /usr/lib/cgi-bin for some reason, > but these are not necessary. Not for Debian, but I guess for our users. Pretending we would deny access to / we better make sure /var/www and /usr/lib/cgi-bin is still served as expected. This is where people will typically install their virtual hosts and/or CGI scripts. We would get lots of fan mail if our new default configuration is going to break that - regardless whether we warn about that or not. > The majority of webapps that add an alias > for some directory don't explicitly allow access to that directory but > depend on access to directory / being allowed. Since we ask web application to update their configurations we could force them to adapt their configuration for that change, too. However, as an alternative we could deny / but allow /usr/share. That sounds like a fair compromise (it's an improvement anyway) as that's where web applications are expected to ship their files. Moreover, that directory is defined to be unmodifiable [1] and thus expected not to contain any sensitive data like configurable passwords, logs and such. > 1) Don't deny access to / but only to some selected directories like > /etc and don't add 'Require all granted' anywhere. Then the admin > could place his access control config inside the <Directory /> block. > The obvious problem is that there will always be some relevant > directories that are forgotten. I oppose for the very same argument. Blacklists are never a good idea to achieve security. We shouldn't consider that until we found any other alternative not doable. > > 2) Use some magical configuration everywhere instead of 'Require all > granted', that would somehow refer to a default access control > configuration. There should be one place where the default access > control would be defined and could be changed. There are some > candidates for using as such magical configuration, but only one is > usable: > > 2.1) <AuthzProviderAlias>: Superficially this is what one wants. > Unfortunately, it always expands to only a single 'Require' statement > (which is too limited) and besides, it's currently broken. > > 2.2) 'Define' the require arguments and then use some variables > instead of all granted. This does not work because the expansion > occurs after word splitting, i.e. the number of words used as Require > arguments would be fixed. Also, it cannot expand to more than one > directive. > > 2.3) 'Include' a special file. This is not usable from .htaccess (not > sure if that is a problem) and adds quite a bit of complexity. Apart > from that, it should be possible. Or, 2.4) use mod_macro - which is not in the standard distribution but would allow us to do such things easily. Moreover, our default site configuration could look much better and more flexible by using that module. Hence adding it as a dependency might be worth a thought or two. That said, it does not solve the general problem: I do not think it is going to scale if we require web application maintainers to obey more and more configuration policies. This increases the chance to do something wrong. Instead we should focus on things which ideally works "as is" to package maintainers. However, looking at existing alternatives that doesn't seem possible in all cases. Looking at the alternatives you outlined I guess the only doable alternatives are 2.3 and 2.4. > > 3) Document that the user should use a <Location /> block to override > the access configuration. Location wins against directory because it > is applied last. But this also means that it wins against the > configuration that made /etc and .ht* unreadable in the first place. A > way around this is to use 'AuthMerging and': I'd rather try to avoid such things. This shifts the entire responsibility to secure the server to the user (or more precisely: keep it secure) as that easily provokes a false sense of security. The problem with that approach is that we're shipping a secure default configuration but literally ask the user to leverage it on purpose. That sounds risky as that's very easy to be misunderstood since forgetting to _add_ a directive i.e. forgetting to add AuthMerging makes _our_ security concept obsolete without yelling loud at the user who might still think his server is secure because of the <Directory> stanzas still in there. Doing that, we could equally just continue to ship our "allow /" configuration and hope/assume the user restricts access. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D
Attachment:
signature.asc
Description: OpenPGP digital signature