4

I have been thinking about the way jvm security works. The principle is that jvm always trusts and runs any native code. So, conceptually if your code does not call checkpermission(permission) whether explicitly or implicitly, it means it will never fail any security validation. Of course, all of these validation calls are usually done in Java API classes so we don't need to call them ourselves for built-in permissions.

Now, as long as you use built-in classes like FileOutputStream, your code is always a subject to permission check. But after thinking for a while I wonder if it is possible to avoid security checks by using Java Native Interface to run c++ code.

Imagine you import some jar that instead of using FileOutputStream to write to a file uses some hand-crafted JNI that binds to file-writing C++ program (which obviously doesn't call any checkpermission()). Based on the question "How to bundle a native library and a JNI library inside a JAR?", I understood that it is possible to bundle everything in a nice malicious jar. So, any code using this jar is not safe anymore since no security validation happens when executing code from the jar. This implies that this c++ program can effectively overwrite all of the files for which the process running jvm has write permissions.

Is it correct way of thinking and it is something intended or am I missing something?

Turkhan Badalov
  • 845
  • 1
  • 11
  • 17

1 Answers1

5

You are right that the native code is out of JVM control. If Java security manager allows loading a JNI library, treat it as if there is no security manager at all.

That's why, if using SecurityManager, it's important not to grant loadLibrary.* permission.

apangin
  • 92,924
  • 10
  • 193
  • 247
  • How am I supposed to load a class over the internet then? I see that we can use UrlClassLoader but not sure how it fits the general picture when I need to load a class from a remote jar file. – Turkhan Badalov Apr 12 '20 at 21:42
  • 2
    @TurkhanBadalov I'm not sure what the problem is. Loading a class from a jar is not the same as loading a native library. You can allow loading classes, but deny loading JNI libraries - these are managed by different permissions. – apangin Apr 12 '20 at 21:45
  • Oh, alright, my bad. So `loadLibrary.*` is specifically for native libraries, got it. Thank you! – Turkhan Badalov Apr 12 '20 at 21:52
  • 2
    @TurkhanBadalov note that native code doesn’t need to implement its own I/O to subvert the security. In a lot of JRE implementations, just setting the field `System.security` to `null` would disable all security checks, an action, even Java code could do when making the mistake of granting it the permission to do reflection with access override. So generally, code should get the minimum permissions needed to do its job, as permissions can have easy-to-overlook implications. – Holger Apr 14 '20 at 15:05
  • This is same as applets and was solved by signing applets to ensure they are safe. – user1889970 Jun 02 '20 at 20:47