• 4
Votes
name
name Punditsdkoslkdosdkoskdo

What does Apache “Require all granted” really do?

I've just update my Apache server to Apache/2.4.6 which is running under Ubuntu 13.04. I used to have a vhost file that had the following:

<Directory "/home/john/development/foobar/web">
    AllowOverride All 
</Directory>

But when I ran that I got a "Forbidden. You don't have permission to access /"

After doing a little bit of googling I found out that to get my site working again I needed to add the following line "Require all granted" so that my vhost looked like this:

<Directory "/home/john/development/foobar/web">
    AllowOverride All 
    Require all granted
</Directory>

I want to know if this is "safe" and does not bring in any security issues. I read on Apache's page that this "mimics the functionality the was previously provided by the 'Allow from all' and 'Deny from all' directives. This provider can take one of two arguments which are 'granted' or 'denied'. The following examples will grant or deny access to all requests."

But it didn't say if this was a security issue of some sort or why we now have to do it when in the past you did not have to.

One of the major changes that Apache 2.4 makes is the preferred way of authorizing users.

Authorization refers to the directives that define what an authenticated user can do. It lays out criteria to check to decide if operations or access should be allowed.

This is different from authentication, which must happen first. Authentication procedures define how a user is able to positively identify themselves to the server. Authentication has not changed much from 2.2, while authorization has gotten an overhaul.

First of all, authorization components can now use the Require syntax that was previously made available for authentication. This creates an easy way to define authorization order rather than relying on complex rule sets. You can instead order them in a logical way, specifying a default and then exceptions.

For instance, you can set a default for accepting traffic, but wish to block a specific malicious user, you can add something like this:

Require all granted
Require not ip 111.111.111.111

This will set a default policy of accepting everybody and then specify a qualifier that the request is not coming from the 111.111.111.111 IP address. To do this, you will need to require both of these to be true, which we will learn how to do momentarily with the RequireAll directive block.

Authorization can be selected not only based on the user or group itself, but also taking into consideration the other factors by using envhost, or ip, or with the catch-all value all.

  • all: This provider matches all traffic. It is useful for setting default values.
  • env: This tests whether an environmental variable is set.
  • host: This is used to test the host name of a connecting client.
  • ip: This is used to test the IP address of the connecting user.

These can be controlled based on the order that they are specified. You will usually see them inside of one of these special blocks:

  • RequireAll: All of the authorization requirements in the block must be fulfilled to allow access.
  • RequireAny: If any of the authorization requirements in this block are met, this block is marked as satisfied.
  • RequireNone: If any of the requirements listed succeed, the directive will fail.

This let's you have quite a bit of flexibility in regards to how you set up authorization. You can nest these directive blocks within one another like this:

<RequireAny>
    <RequireAll>
        Require user root
        Require ip 123.123.123.123
    </RequireAll>
    <RequireAll>
        <RequireAny>
            Require group sysadmins
            Require group useraccounts
            Require user anthony
        </RequireAny>
        <RequireNone>
            Require group restrictedadmin
            Require host bad.host.com
        </RequireNone>
    </RequireAll>
</RequireAny>

As you can see, we can define some pretty elaborate authorization paths. The above example will authorize if the user is root and coming from the IP 123.123.123.123. It will also authorize a user named "anthony" or any members of the groups "sysadmins" or "useraccounts", but ONLY if they are not also part of the "restrictedadmin" group or coming from a flagged host at bad.host.com.

These authentication blocks are much easier to understand than the classic directives that were used for access control. In past versions of Apache, you would use the OrderAllow fromDeny from, and Satisfy directives. These have not been removed, but have been deprecated in favor of the new syntax, which is easier to understand and more consistent.

They have however, been moved to a separate module called mod_access_compat. Make sure you enable this module if you require the legacy authorization directives. However, I would suggest implementing your conditions in the new syntax, both for future support, and because it is significantly easier to figure out the implications of the policies you are selecting.

  • 2
Reply Report

I know it is an old post but i think that can help more with a functional example that i always use!

In apache 2.2 would be like:

    <Location />
       Order deny, allow
       allow from all
    </Location>
    <Location /adm>
        Order deny, allow
        deny from all
        allow from myniceip
    </Location>
    <Location /disabled>
        Order deny, allow
        deny from all
    </Location>

In apache 2.4 would be like:

   <Location />
       require all granted
    </Location>
   #Note that you dont need to use require all denied
   #to require only a group of ips.. 
    <Location /adm>
        require ip myniceip
    </Location>
    <Location /disabled>
        Require all denied
    </Location>
  • 2
Reply Report

The access control configuration changed in 2.4, and old configurations aren't compatible without some changes. See here.

If your old config was Allow from all (no IP addresses blocked from accessing the service), then Require all granted is the new functional equivile

  • 2
Reply Report