fix(aop): add JCE crypto-policy read exemption to the AspectJ backend

Author: LukaPetrovicTUM

src/main/java/de/tum/cit/ase/ares/api/aop/java/aspectj/adviceandpointcut/JavaAspectJAbstractAdviceDefinitions.aj

@@ -354,6 +354,29 @@ public abstract aspect JavaAspectJAbstractAdviceDefinitions {
 		});
 	}
 
+	/**
+	 * Returns {@code true} when the current call stack is inside
+	 * {@code javax.crypto.JceSecurity}'s own JCE jurisdiction-policy scan (its
+	 * static initialiser calls {@code Files.newDirectoryStream} with the fixed
+	 * {@code {default,exempt}_*.policy} glob against the real {@code java.home}
+	 * policy directory). The signal is precise and cannot be spoofed: a student
+	 * calling the same JDK file-system APIs directly, even with an identical file
+	 * name or glob argument, has no {@code JceSecurity} frame between their own
+	 * code and the read, so such an access stays blocked. Because
+	 * {@code JceSecurity} never takes a student-influenceable path/glob argument,
+	 * this frame check alone precisely identifies the genuine JVM-triggered scan —
+	 * no additional location check on the intercepted argument is needed or
+	 * possible, since the bare glob argument resolves against the working
+	 * directory, not {@code java.home}, when converted to a path.
+	 *
+	 * @return {@code true} if a {@code javax.crypto.JceSecurity} frame is present
+	 *         on the current stack
+	 */
+	static boolean isJceCryptoPolicyScanInProgress() {
+		return STACK_WALKER.walk(
+				frames -> frames.map(StackWalker.StackFrame::getClassName).anyMatch(className -> className.startsWith("javax.crypto.JceSecurity")));
+	}
+
 	/**
 	 * Returns {@code true} only while Ares itself is reading framework support
 	 * files for structural and architecture test setup through one of its trusted

src/main/java/de/tum/cit/ase/ares/api/aop/java/aspectj/adviceandpointcut/JavaAspectJFileSystemAdviceDefinitions.aj

@@ -1215,32 +1215,39 @@ public aspect JavaAspectJFileSystemAdviceDefinitions extends JavaAspectJAbstract
 	 * infrastructure, not student file access; blocking it makes cryptography fail
 	 * to initialise ({@code NoClassDefFoundError} / "Can not initialize
 	 * cryptographic mechanism"). The instrumentation backend applies this same
-	 * exemption, so this keeps the two backends consistent. The match requires the
-	 * path to resolve under the trusted JDK installation ({@code java.home}) in
-	 * addition to the JCE policy naming scheme, so a student-controlled file
-	 * living outside {@code java.home} cannot bypass the read policy merely by
-	 * being given one of the exempt names.
+	 * exemption, so this keeps the two backends consistent. The bare
+	 * {@code {default,exempt}_*.policy} directory-scan glob is not itself a real
+	 * file path — it resolves against the working directory, not
+	 * {@code java.home}, when converted to a path — so a location check on the
+	 * intercepted argument cannot validate it. The match instead requires the
+	 * access to originate from {@code javax.crypto.JceSecurity}'s own scan (see
+	 * {@link #isJceCryptoPolicyScanInProgress()}), which a student cannot spoof
+	 * and which never takes a student-influenceable path/glob argument, so a
+	 * student-controlled file (or a directly-called {@code newDirectoryStream}
+	 * with the same glob) cannot bypass the read policy merely by matching one of
+	 * the exempt names.
 	 *
 	 * @param path the already-resolved path string under inspection
-	 * @return true if the path is a JCE crypto policy file or scan glob
+	 * @return true if the path is a JCE crypto policy file or scan glob read by a
+	 *         genuine JCE-triggered scan
 	 */
 	private static boolean isCryptoPolicyPath(@Nullable String path) {
 		if (path == null) {
 			return false;
 		}
-		// SECURITY: The name match alone is not sufficient — a student-controlled file
-		// living outside java.home could be given one of these exact names to bypass the
-		// read policy. Require the path to actually resolve under the trusted JDK
-		// installation first, the same trust root isExemptSystemFileAccess uses.
-		if (!isPathWithin(path, TRUSTED_JAVA_HOME)) {
-			return false;
-		}
 		int slash = path.lastIndexOf('/');
 		String name = slash >= 0 ? path.substring(slash + 1) : path;
 		// Match only the fixed JCE jurisdiction-policy file names and the exact
 		// directory-scan glob JceSecurity uses, never an arbitrary "default_*"/"exempt_*"
 		// prefix, so a student-named file such as "default_tokens.policy" is NOT exempt.
-		return CRYPTO_POLICY_NAMES.contains(name);
+		if (!CRYPTO_POLICY_NAMES.contains(name)) {
+			return false;
+		}
+		// SECURITY: the name match alone is not sufficient — a student-controlled file
+		// (or a directly student-called newDirectoryStream) could bear one of these
+		// exact names/glob to bypass the read policy. Require the read to actually
+		// originate from JCE's own scanning code.
+		return isJceCryptoPolicyScanInProgress();
 	}
 
 	/**

src/main/java/de/tum/cit/ase/ares/api/aop/java/instrumentation/advice/JavaInstrumentationAdviceAbstractToolbox.java

@@ -343,6 +343,29 @@ static boolean isClassLoadingInProgress() {
 		});
 	}
 
+	/**
+	 * Returns {@code true} when the current call stack is inside
+	 * {@code javax.crypto.JceSecurity}'s own JCE jurisdiction-policy scan (its
+	 * static initialiser calls {@code Files.newDirectoryStream} with the fixed
+	 * {@code {default,exempt}_*.policy} glob against the real {@code java.home}
+	 * policy directory). The signal is precise and cannot be spoofed: a student
+	 * calling the same JDK file-system APIs directly, even with an identical file
+	 * name or glob argument, has no {@code JceSecurity} frame between their own
+	 * code and the read, so such an access stays blocked. Because
+	 * {@code JceSecurity} never takes a student-influenceable path/glob argument,
+	 * this frame check alone precisely identifies the genuine JVM-triggered scan —
+	 * no additional location check on the intercepted argument is needed or
+	 * possible, since the bare glob argument resolves against the working
+	 * directory, not {@code java.home}, when converted to a path.
+	 *
+	 * @return {@code true} if a {@code javax.crypto.JceSecurity} frame is present
+	 *         on the current stack
+	 */
+	static boolean isJceCryptoPolicyScanInProgress() {
+		return STACK_WALKER.walk(frames -> frames.map(StackWalker.StackFrame::getClassName)
+				.anyMatch(className -> className.startsWith("javax.crypto.JceSecurity")));
+	}
+
 	/**
 	 * Returns {@code true} only while Ares itself is reading framework support
 	 * files for structural and architecture test setup through one of its trusted

src/main/java/de/tum/cit/ase/ares/api/aop/java/instrumentation/advice/JavaInstrumentationAdviceFileSystemToolbox.java

@@ -1333,35 +1333,41 @@ private static boolean isJdkNativeLibraryLoad(@Nonnull String path) {
 	 * infrastructure, not student file access; blocking it makes cryptography fail
 	 * to initialise ({@code NoClassDefFoundError} / "Can not initialize
 	 * cryptographic mechanism"). The AspectJ backend applies this same exemption,
-	 * so this keeps the two backends consistent. The match requires the path to
-	 * resolve under the trusted JDK installation ({@code java.home}) in addition to
-	 * the JCE policy naming scheme, so a student-controlled file living outside
-	 * {@code java.home} cannot bypass the read policy merely by being given one of
-	 * the exempt names.
+	 * so this keeps the two backends consistent. The bare
+	 * {@code {default,exempt}_*.policy} directory-scan glob is not itself a real
+	 * file path — it resolves against the working directory, not {@code java.home},
+	 * when converted to a path — so a location check on the intercepted argument
+	 * cannot validate it. The match instead requires the access to originate from
+	 * {@code javax.crypto.JceSecurity}'s own scan (see
+	 * {@link #isJceCryptoPolicyScanInProgress()}), which a student cannot spoof and
+	 * which never takes a student-influenceable path/glob argument, so a
+	 * student-controlled file (or a directly-called {@code newDirectoryStream} with
+	 * the same glob) cannot bypass the read policy merely by matching one of the
+	 * exempt names.
 	 *
 	 * @param path the already-resolved path string under inspection
-	 * @return true if the path is a JCE crypto policy file or scan glob
+	 * @return true if the path is a JCE crypto policy file or scan glob read by a
+	 *         genuine JCE-triggered scan
 	 */
 	private static boolean isCryptoPolicyPath(@Nullable String path) {
 		if (path == null) {
 			return false;
 		}
-		// SECURITY: The name match alone is not sufficient — a student-controlled file
-		// living outside java.home could be given one of these exact names to bypass
-		// the
-		// read policy. Require the path to actually resolve under the trusted JDK
-		// installation first, the same trust root isExemptSystemFileAccess uses.
-		if (!isPathWithin(path, TRUSTED_JAVA_HOME)) {
-			return false;
-		}
 		int slash = path.lastIndexOf('/');
 		String name = slash >= 0 ? path.substring(slash + 1) : path;
 		// Match only the fixed JCE jurisdiction-policy file names and the exact
 		// directory-scan glob JceSecurity uses, never an arbitrary
 		// "default_*"/"exempt_*"
 		// prefix, so a student-named file such as "default_tokens.policy" is NOT
 		// exempt.
-		return CRYPTO_POLICY_NAMES.contains(name);
+		if (!CRYPTO_POLICY_NAMES.contains(name)) {
+			return false;
+		}
+		// SECURITY: the name match alone is not sufficient — a student-controlled file
+		// (or a directly student-called newDirectoryStream) could bear one of these
+		// exact names/glob to bypass the read policy. Require the read to actually
+		// originate from JCE's own scanning code.
+		return isJceCryptoPolicyScanInProgress();
 	}
 
 	/**