Is your feature request related to a problem? Please describe.
When using the SecurePolicyWriter tool to generate policy files that comply with the principle of least privilege, it does so as a single policy file for the entire JVM.
AggregatePolicyProvider and LoaderSplitPolicyProvider split policy files into context ClassLoader and ClassLoader visible policy's, the problem is that these are not generated automatically, the intent is to limit the permissions granted to each ClassLoader due to identical CodeSource's being loaded by multiple ClassLoader's for different Services. However the result of these providers is they are usually granted AllPermission and run elevated privileges in comparison to a single policy generated to POLP principles.
The reason this is important is that DeSerializationPermission should only be granted to client principals, this ensures that data being deserialized is trustworthy. If AllPermission is granted to code, then it allows deserialization of untrusted data.
Describe the solution you'd like
Remove AggregatePolicyProvider and LoaderSplitPolicyProvider
Describe alternatives you've considered
Attempt to generate policy files to least privilege using a Policy.
The problem with this approach is the Policy isn't always consulted, so we would miss permissions adding to complexity. The SecurityManager is always consulted. The additional complexity of multiple policy files per JVM is unwarranted.
Is your feature request related to a problem? Please describe. When using the SecurePolicyWriter tool to generate policy files that comply with the principle of least privilege, it does so as a single policy file for the entire JVM.
AggregatePolicyProvider and LoaderSplitPolicyProvider split policy files into context ClassLoader and ClassLoader visible policy's, the problem is that these are not generated automatically, the intent is to limit the permissions granted to each ClassLoader due to identical CodeSource's being loaded by multiple ClassLoader's for different Services. However the result of these providers is they are usually granted AllPermission and run elevated privileges in comparison to a single policy generated to POLP principles.
The reason this is important is that DeSerializationPermission should only be granted to client principals, this ensures that data being deserialized is trustworthy. If AllPermission is granted to code, then it allows deserialization of untrusted data.
Describe the solution you'd like Remove AggregatePolicyProvider and LoaderSplitPolicyProvider
Describe alternatives you've considered Attempt to generate policy files to least privilege using a Policy. The problem with this approach is the Policy isn't always consulted, so we would miss permissions adding to complexity. The SecurityManager is always consulted. The additional complexity of multiple policy files per JVM is unwarranted.