Bug 752: Review Code Vulnerabilities (Permission Checks of new exposed code and privileged access)

This review focuses on how we perform permission checks,
or better - do we circumvent some assuming full privileges ?
Some native methods do need extra permission validation, i.e. loading native libraries.

Further more AccessController.doPrivileged(..) shall not cover generic code
exposing a critical feature to the user.

Further more .. we should rely on the SecuritManager, i.e. AccessControlContext's
'checkPermission(Permission)' code to comply w/ fine grained permission access.

It is also possible to have full permission w/o having any certificates (-> policy file).

+++

We remove implicit AccessController.doPrivileged(..) from within our trusted code
for generic methods, like Property access, temp. files.

+++

SecurityUtil:
 - Remove 'getCommonAccessControlContext(Class<?> clz)',
   which returned a local AccessControlContext for later restriction
   if the passed class contains all certificates as the 'trusted' GlueGen class has.

 - Simply expose convenient permission check methods relying on
   SecurityManager / AccessControlContext.

PropertyAccess:
 - 'protected static void addTrustedPrefix(..)' requires AllPermissions if SecurityManager is installed.
 - Remove implicit doPrivileged(..) triggered by passed AccessControlContext instance,
   only leave it for trusted prefixes.

IOUtil:
  - Remove all doPrivileged(..) - Elevation shall be performed by caller.

DynamicLinker:
  - 'public long openLibraryLocal(..)' and 'public long openLibraryGlobal(..)'
    may throw SecurityException, if a SecurityManager is installed and the dyn. link permission
    is not granted in the calling code.
    Implemented in their respective Unix, OSX and Windows manifestation.

    Caller has to elevate privileges via 'doPrivileged(..) {}' !

+++

Tests:
 - Property access
 - File access
 - Native library loading

Manual Applet test (unsigned, but w/ SecurityManager and policy file):
  > gluegen/test/applet

  Applet has been tested w/ signed JAR w/ Firefox and Java7 on GNU/Linux as well.

Manual Application test (unsigned, but w/ SecurityManager and policy file):
  com.jogamp.junit.sec.TestSecIOUtil01

  - Run w/ SecurityManager and policy file:
    - gluegen/scripts/runtest-secmgr.sh

  - Run w/o SecurityManager:
    - gluegen/scripts/runtest.sh

1 files changed, 5 insertions, 2 deletions

diff --git a/src/java/jogamp/common/os/MacOSXDynamicLinkerImpl.java b/src/java/jogamp/common/os/MacOSXDynamicLinkerImpl.java
index 4eb381f..95f7e63 100644
--- a/src/java/jogamp/common/os/MacOSXDynamicLinkerImpl.java
+++ b/src/java/jogamp/common/os/MacOSXDynamicLinkerImpl.java
@@ -3,6 +3,7 @@
 package jogamp.common.os;
 
 import com.jogamp.common.os.DynamicLinker;
+import com.jogamp.common.util.SecurityUtil;
 
 
 public class MacOSXDynamicLinkerImpl implements DynamicLinker {
@@ -28,7 +29,7 @@ public class MacOSXDynamicLinkerImpl implements DynamicLinker {
 
 
   // --- Begin CustomJavaCode .cfg declarations
-  public long openLibraryLocal(String pathname, boolean debug) {
+  public long openLibraryLocal(String pathname, boolean debug) throws SecurityException {
     // Note we use RTLD_LOCAL visibility to _NOT_ allow this functionality to
     // be used to pre-resolve dependent libraries of JNI code without
     // requiring that all references to symbols in those libraries be
@@ -36,10 +37,11 @@ public class MacOSXDynamicLinkerImpl implements DynamicLinker {
     // other words, one can actually link against the library instead of
     // having to dlsym all entry points. System.loadLibrary() uses
     // RTLD_LOCAL visibility so can't be used for this purpose.
+    SecurityUtil.checkLinkPermission(pathname);
     return dlopen(pathname, RTLD_LAZY | RTLD_LOCAL);
   }
   
-  public long openLibraryGlobal(String pathname, boolean debug) {
+  public long openLibraryGlobal(String pathname, boolean debug) throws SecurityException {
     // Note we use RTLD_GLOBAL visibility to allow this functionality to
     // be used to pre-resolve dependent libraries of JNI code without
     // requiring that all references to symbols in those libraries be
@@ -47,6 +49,7 @@ public class MacOSXDynamicLinkerImpl implements DynamicLinker {
     // other words, one can actually link against the library instead of
     // having to dlsym all entry points. System.loadLibrary() uses
     // RTLD_LOCAL visibility so can't be used for this purpose.
+    SecurityUtil.checkLinkPermission(pathname);
     return dlopen(pathname, RTLD_LAZY | RTLD_GLOBAL);
   }