Security Policy with denying rules

[Sean Mullan]

Hi Ondrej,

Thanks for sharing the information about your project. If you have a 
copy of the book "Inside Java 2 Platform Security" [1], there is a 
section (5.1.5) discussing the rationale for not including support for 
"negative" permissions in the Java Security model. The section talks 
about the reasons for not supporting them, particularly that there can 
never be any conflict between positive permissions. This makes it 
simpler to implement and also safer since there is no need to check for 
conflicts, and there is less of an unknown factor in what permissions 
are actually being granted. The book also discusses another potential 
solution whereby you could preprocess the negative permissions into a 
policy file containing only positive permissions. Requests for negative 
permissions come up every now and then, so I think it is useful to 
discuss it some more.

Anyway, I don't necessarily want to discourage you but I was just 
wondering if you have thought about any of these issues.

Thanks,
Sean

[1] 
http://www.amazon.com/Inside-Java%C2%BF-Platform-Security-Implementation/dp/0201787911

On 01/17/2014 03:39 AM, Ondřej Lukáš wrote:
> Hi,
> I've implemented Java Security Manager and Policy for using denying
> rules and I think that maybe someone will be interested in it. Standard
> Java Policy [1] uses only granting permissions and there are cases when
> denying rules are more comfortable than granting rules. I would like to
> know your opinion and get some feedback if you'll be interested. Project
> is called Prograde (Policy Rules Of GRanting And DEnying) and you can
> use it as maven artifact:
>
> <dependency>
>    <groupId>net.sourceforge.pro-grade</groupId>
>    <artifactId>pro-grade</artifactId>
>    <version>1.0</version>
> </dependency>
>
> Project is also available through github [2] and some tests are in
> progradeTests project [3].
>
> In the README files of these two github projects is some information
> about using policy with denying rules. Usage is similar as with standard
> policy, but you can write also deny entry (keyword "deny") instead of
> grant. There is a new entry named "priority" which is set to grant or
> deny value - it says whether grant or deny rule is used if they are in
> conflict. Some examples of policy files are used in [3].
>
> I think that the main advantage of this type of policy rules and
> Prograde project is simplification of testing. Sometimes you want to
> know what behavior will your application have in case that some specific
> permission isn't granted. In this case you need to grant everything
> except that permission, so a denying rule is the best option.
>
> There are also some imperfections, but I think that they are not so
> important:
> - Prograde is not able to work with general expansion [4]. (property
> expansion works fine)
> - Path used in codebase entry must contain only a-z, A-Z, 0-9 and some
> symbols defined in encodeSpecialCharacters protected method of
> net.sourceforge.prograde.policy.ProgradePolicyFile class.
>
> I am planning to fix it in future releases.
>
> I hope Prograde will be helpful for somebody and I'll be happy for every
> feedback.
>
> Best regards,
> Ondrej Lukas
>
> [1]
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html
> [2] https://github.com/olukas/pro-grade
> [3] https://github.com/olukas/progradeTests
> [4]
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html#GeneralExp