How can the permit-unless-deny combining algorithm be dangerous?

Mark Berg   ·   Wednesday, November 16th, 2016

Background

We haven’t discussed combining algorithms much, but they are just one of the many powerful features of an XACML-based authorization system.  You can think of combining algorithms as a way to assign weight to many partial answers to the same question.  Let’s use a background check as an example.  A background check has many different questions/tests in it, but how do you determine if someone passes or fails?  The administrator of the background check combines all of the individual answers to produce a final, all-encompassing pass/fail result.  They know which tests carry more weight and combine the results accordingly.  If you prefer a technical mumbo jumbo explanation, you can check out this post which also includes a truth table which explains how results are combined in XACML.

While working with customers, I’m often asked, “Which combining algorithm should I use?” to which I usually answer with, “It depends.”  Answering that question requires not only knowledge of combining algorithms, but also a known policy structure and a good understanding of the authorization rules for a given use case.  Trying to discuss all of that here might not be a good idea. Instead, let’s focus on a piece of the puzzle, and over time, we will try to paint a complete picture.

Using permit-unless-deny with care

As with any system, it is a best practice to understand not only all of the options available, but also the impact of those options.  For example, using the permit-unless-deny combining algorithm can be dangerous.  This combining algorithm often gets used in cases where it isn’t possible to define all of the conditions that are required to permit access, and instead, there is only a list of conditions under which access should be denied.

Consider the following example of allowing intergalactic travelers to visit Earth.

The universe has millions of planets in it, and new planets are being discovered all the time.  Worm holes and rifts in the space time continuum allow life forms from these planets to travel great distances, and people want to visit Earth to take a selfie with the World Series trophy at Wrigley Field.   It simply isn’t possible for us to define a list of all planets from which we accept visitors, but since the universe has mostly good planets, we can define a list of planets from which visitors are not allowed.  So, our intergalactic visitor policy is:

Life forms from the following planets should not be allowed:

• Q’onoS

• Romulus

The XACML policy for this would be this: 

policyset earth {
    target clause planet.name == "Earth"
    apply firstApplicable
    policy visit {
     target clause action.name == "visit" and object == "planet"
     apply permitUnlessDeny
     rule bannedHomeWorlds{
        deny
        target clause user.homeWorld == "Q'onoS" or user.homeWorld == "Romulus"
      }
   }
}

Table 1: sample policy with an unsafe use of permitUnlessDeny

The problem with the above policy is, if someone doesn’t have their intergalactic passport, they will be allowed in, because not having a home planet is the same as not being from one of the banned planets.  This could be dangerous.  If someone’s intent was to destroy Major League Baseball and replace it with their favorite sport Pyramid or Blernsball it would be very easy for them to gain access to Earth.

A safer implementation of this type of a policy is:

policyset earthSafer{
   target clause planet.name == "Earth"
   apply firstApplicable
   policy visitSafer {
      target clause action.name == "visit" and object == "planet"
      apply permitUnlessDeny
      rule hasDeclaredHomeWorld{
         deny
         condition stringBagSize(user.homeWorld) == 0
      }
      rule bannedHomeWorlds{
         deny
         target clause user.homeWorld == "Q'onoS" or user.homeWorld == "Romulus"
      }
   }
}

Table 2: sample policy with a safer use of permitUnlessDeny

The safer version of this policy ensures that each visitor has declared their home world by checking that the attribute user.homeWorld has at least one value.  This is done by the rule hasDeclaredHomeWorld.  By checking that the critical attribute user.homeWorld exists, this policy just became much safer.

Conclusion

There are times when it might not possible to define all of the conditions that must exist in order for access to be permitted.  For those situations where it is only possible to define a set of conditions that must not exist, using the permit-unless-deny combining algorithm might be a good choice. Just make sure you have safety measures in place to check for the existence of key attributes where needed. Using the permit-unless-deny combining algorithm isn’t like boldly going where no person has gone before, but make sure you understand the potential implications of using it. 

Live long and XACML.