Thoughts about the default auth/access configuration
Hi,
I have made some experiments and spent some thoughts on the default
authorization configuration. I will outline some things that have to
be taken into account, first.
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*
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. 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.
It would be nice to forbid access to sensitive directories like /etc,
so that even in case of config errors of e.g. mod_rewrite, no files
from that directory would be served. An obvious approach would be to
add
<Directory />
Require all denied
</Directory>
This would make it necessary that all webapps allow access to their
respective document directories. The straightforward way would be to
add
Alias /webappX /usr/share/webappX/docs
<Directory /usr/share/webappX/docs>
Require all granted
</Directory>
Now a problem occurs if the admin wants add some access control to the
whole server, say 'Require valid-user' or 'Require ip 10.0.0.0/8'.
Obviously, changing all occurences of 'Require all granted' for every
webapp does not scale. There are several possible solutions:
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.
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.
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':
<Location />
AuthMerging and
Require ip 10.0.0.0/8
</Location>
This means that the most previous auth config in the config merge
order must also allow access, or access to the site will be denied.
This has some issues because it may not always be obvious which is the
most previous auth config in the config merge order. And the admin
must always add it, or he will loose the protection for /etc and .ht*.
4) Use 'AuthMerging and' by default. This is currently not possible.
'AuthMerging' only affect the one block of auth config where it
appears and is not inherited.
In addition to the general problem, there are some URLs like /server-
status, /server-info, /ldap-status, that disclose sensitive
informations. These need special protection. Currentlly, this is done
by only allowing access from localhost. Then there are some even more
sensitive URLs like /jk-status and /balancer-manager which even allow
to change the configuration. Currently, these are commented out.
Using the 'Include' approach (2.3) would have the advantage that one
could use a different file for the status URLs and the admin could
then easily change the access config for these, too. But somehow I
don't like using even more included files. It would make the
configuration even more difficult to understand and be less in line to
what upstream uses. Therefore, I lean towards using the recommend
"AuthMerging and" approach (3).
Any other thoughts and opinions are very welcome.
Cheers,
Stefan
Reply to: