[FeatureRequest]: Standard-allow low-risk JDK-internal operations in the secure baseline policy

[LukaPetrovicTUM]

Is your feature request related to a problem?

Under a maximally restrictive policy, Ares 2 still denies a number of ordinary, low-risk operations that standard JDK code performs internally and that carry no meaningful security risk, forcing instructors to discover and explicitly allow each one, exercise by exercise. Enforcement runs through two independent engines, AspectJ and instrumentation (the file-system checks live under aop/java/aspectj and aop/java/instrumentation), that are each supposed to reach the same verdict for the same input. Several of the gaps below are really two-sided: one engine may already handle a case while the other doesn't, or the two handle it by different, inconsistent rules.

1. The exemption that lets cryptography setup read its own configuration files is unreliable and one-sided: it exists on only one of the two engines, and even there it recognizes those files by name alone, with no check on where the file actually is or what's genuinely asking for it, so a student-supplied file with a matching name can ride along on the exemption.
2. Both engines already exempt reads of trusted archive files, but by different, inconsistent rules: one allows by call shape (an already-open archive's entry reads, never the call that opens the archive in the first place), the other allows by location (anything under a trusted system path, including the call that opens the archive). A read that's exempt under one engine's rule is not necessarily exempt under the other's, so the two engines can disagree on identical input.
3. Reading system entropy sources (used for random-number generation) is not yet standard-allowed on either engine.
4. Reading the system's configured time zone is not yet standard-allowed on either engine.
5. Reading the system's trusted-certificate store already works today without extra configuration, but nothing proves and locks in that this is intentional, verified behaviour rather than an accident of a broader exemption.
6. Reading locale/language formatting data has the same situation as the certificate store above. It already works via a shared, broader exemption, but has no dedicated verification of its own anywhere.
7. Creating a temporary file in the JVM's own default temporary location (Files.createTempFile/File.createTempFile) is not yet standard-allowed. Every exercise currently needs its own explicit permission for this common, low-risk operation. Getting this right is not trivial: this kind of narrow, low-risk-looking exemption has already turned out to be easy to get wrong in ways that quietly let a student-chosen location bypass the policy entirely, so any implementation needs to be checked carefully against that failure mode.
8. There's no single, referenceable overview telling instructors what the baseline already allows without an explicit policy entry. They currently have to discover this by trial and error.
9. Internal documentation about what happens when no explicit permissions are configured says the opposite of what the system actually (correctly) does, a misleading, if harmless, inconsistency.
10. There's no automated check that the two enforcement engines actually agree on every one of these exemptions. BlacklistParityTest.java is the existing structural precedent for this kind of check, just for a different subsystem. Today agreement between the two engines is asserted by hand and has already been shown to be wrong in at least one case (see point 1), a case that went unnoticed until specifically investigated.

Describe the solution you'd like

• Fix the cryptography-configuration-file exemption so both engines carry it, and so it recognizes only genuine, trusted internal reads rather than matching on filename or on any code path that merely happens to run near the trusted one.
• Unify the trusted-archive-read exemption's criteria across both engines (call shape vs. location), or, if a deliberate difference is kept, document why next to both implementations.
• Add standard-allow exemptions for entropy-source reads and system time-zone reads, on both engines, following the same careful, narrowly-scoped approach already used for the existing exemptions.
• Add regression tests that specifically lock in the already-working certificate-store and locale/charset behaviour, so a future change can't silently break either without a test failing.
• Add a standard-allow exemption for default-location temporary-file creation, with explicit attention to closing off any way a student-supplied path could be mistaken for the default location.
• Publish a short, referenceable overview of everything the baseline already allows by default (cross-referenced from docs/policy/SecurityPolicyManual.md), so instructors don't have to read source code to find out.
• Fix the incorrect documentation about default-deny behaviour.
• Add an automated test, following the BlacklistParityTest.java pattern, that runs each of these exemptions through both enforcement engines and checks they produce the same result, so a future divergence is caught by CI rather than by manual review.

Describe alternatives you've considered

Tracking each of the above as its own issue. Rejected: they all sit on the same baseline allow-list, share the same two-engine-parity requirement, and are individually small enough that separate tracking mostly added overhead without helping prioritisation.

Additional context

This is the full remaining scope of the secure-baseline-policy refinement effort: standard-allowing a narrow, justified set of low-risk operations while keeping everything else denied by default. Verification for any of the above should run the full {ArchUnit, WALA} × {AspectJ, instrumentation} test matrix (mvn test -Parchitecture-tests / -Pintegration-core-tests), not just one combination. See the existing integration/aop/{allowed,forbidden} test suites for the established pattern.