JNA trying to read files in /proc - but I'm on macOS, not Linux

[hakanai]

We were on JNA 3.5.x and recently updated to 4.4.x.

Now we get the following error:

java.lang.ExceptionInInitializerError
	at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:936)
	at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:922)
	at com.sun.jna.Native.<clinit>(Native.java:190)
	at com.acme.common.jna.CLibrary.<clinit>(CLibrary.java:20)
        ... truncating test framework ...
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/proc/self/exe" "read")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
	at java.security.AccessController.checkPermission(AccessController.java:884)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
	at java.io.RandomAccessFile.<init>(RandomAccessFile.java:229)
	at java.io.RandomAccessFile.<init>(RandomAccessFile.java:124)
	at com.sun.jna.ELFAnalyser.runDetection(ELFAnalyser.java:109)
	at com.sun.jna.ELFAnalyser.analyse(ELFAnalyser.java:36)
	at com.sun.jna.Platform.isSoftFloat(Platform.java:259)
	at com.sun.jna.Platform.<clinit>(Platform.java:133)
	... 45 more

It seems like JNA should not be doing what looks like some kind of ELF-specific processing when I'm running on macOS.

[matthiasblaesing]

/proc/self/exe and the target of that symlink are analyzed to determine the platform on which JNA is run. This was introduced to support running JNA on linux arm-hardfloat and arm-softfloat (mapped to armel). The only way to reliably determine the correct platform is to analyze the java binary, that is running the application.

Please check if you can relax the security manager restrictions. The security manager only works on the java level. If the code gets access the the JNA library and is able to load a interface for the C library, the files will be accessible via the C functions.

As a potential fix I see the option to modify: com.sun.jna.Platform.isSoftFloat() like this:

--- a/src/com/sun/jna/Platform.java
+++ b/src/com/sun/jna/Platform.java
@@ -260,7 +260,10 @@
             return ahfd.isArmSoftFloat();
         } catch (IOException ex) {
             // asume hardfloat
-            Logger.getLogger(Platform.class.getName()).log(Level.FINE, null, ex);
+            Logger.getLogger(Platform.class.getName()).log(Level.FINE, "Failed to read '/proc/self/exe' or the target binary.", ex);
+        } catch (SecurityException ex) {
+            // asume hardfloat
+            Logger.getLogger(Platform.class.getName()).log(Level.FINE, "SecurityException while analysing '/proc/self/exe' or the target binary.", ex);
         }
         return false;
     }

[hakanai]

That would work. The check could alternatively be delayed until you know you're running on ARM Linux, since the value it computes is only used in that situation.

[matthiasblaesing]

@trejkaz did you evaluate just relaxing the security manager rules? As said: The moment a call into JNA is possible, you can safely say all bets are off.

[hakanai]

I'm not sure we want to relax the rule for reading from /proc. It's a portability issue more than anything, and none of the platforms we run on is ARM so the reason JNA has to do the check is irrelevant to our application. If it could delay the check until after it knows that it's ARM Linux...

Just catching the exception would be fine by me too, though.

(I have wondered about the security risks of having JNA on the classpath too, actually... It would probably be fine if all the methods properly checked with the SecurityManager before running, but currently they don't. Our own code generally does before calling it, but an attacker obviously bother.)

[matthiasblaesing]

@trejkaz I merged the fix. I would have liked to see a more serious analysis and evaluation.