ProxySG Content Policy Language Guide
The following example is an exception defined within a layer. A company wants access to payroll information limited to Human Resources staff only. The administrator uses membership in the HR_staff group to define the exception for HR staff, followed by the general policy:
<Proxy>
;Blue Coat uses groups to identify HR staff, so authentication is required authenticate(MyRealm)
define condition payroll_location url=hr.my_company.com/payroll/
end
<Proxy> condition=payroll_location allow group=HR_staff ; exception deny ; general rule
This approach requires that the policy be in one layer, and because layer definitions cannot be split across policy files, the rule and the exceptions must appear in the same file. That may not work in cases where the rules and the exceptions are maintained by different groups.
However, this is the preferred technique, as it maintains all policy related to the payroll files in one place. This approach can be used in either blacklist or whitelist models (see "Blacklists and Whitelists" on page 45) and can be written so that no security holes are opened in error. The example above is a whitelist model, with everything not explicitly mentioned left to the default rule of deny.
Using Layer Ordering to Define Exceptions
Since later layers override earlier layers, general rules can be written in one layer, with exceptions written in following layers, put specific exceptions later in the file.
The Human Resources example could be rewritten as:
<Proxy>
;Blue Coat uses groups to identify HR staff, so authentication is required authenticate(MyRealm)
define condition payroll_location url=hr.my_company.com/payroll/
end
<Proxy>
condition=payroll_location deny ; general rule
<Proxy>
condition=payroll_location allow group=HR_staff ; exception
Notice that in this approach, some repetition is required for the common condition between the layers. In this example, the condition=payroll_location must be repeated. It is very important to keep the exception from inadvertently allowing other restrictions to be undone by the use of allow.
As the layer definitions are independent, they can be installed in separate files, possibly with different authors. Definitions, such as the payroll location condition, can be located in one file and referenced in another. When linking rules to definitions in other files, file order is not important, but the order of installation is. Definitions must be installed before policy that references them will compile. Keeping definitions used across files in only one of the files, rather than spreading them out, will eliminate the possibility of having changes rejected because of interlocking reference problems. Note that when using this approach, exceptions must follow the general rule, and you must be aware of the policy file
46
