So, actually I could just as well check the html javadocs
for the SDK :-)

I'd lookup all platform methods called from the program's code,
in the javadoc, and see if any of these is documented to throw an SE.

Thanks. That might identify me some further suspicious methods...

   A static analyzer and a VM are different tools and tend to be used in
different situations. VMs are typically useful if you actually want to run
the program. Static analyzers are typically useful if you want to obtain
information about a program without actually running it. Usually you can't
interchange one for the other, unless the program is completely
deterministic (e.g. its behaviour doesn't depend on user input, or the
contents of files, etc.)

   - Oliver

I don't quite seem to understand.
If I run a jar-file with "java -jar app.jar", the only
"other" class files that can be picked up are those
explictly mentioned in the classpath plus those in
in the jre's lib/ext/ directory.

If I have some toy-program.jar, I don't add any extra jar-files
to the classpath, nor do I put jar files into the ext dir, unless
they contain only packages that I would recognize as belonging to
these jar-files (if the toy-program was to try to call them).

An application can catch all the SecurityExceptions it runs against,
so I don't ever see (not even if I single-step through it in a
debugger), what the app really does, until I once (in a weak moment)
run it unrestricted.

It's something of a truism of security that, in any complex system, attempting
to create a "blacklist" of disallowed operations is going to leave holes.  The
"normal" (i.e. best) practise is to use a whitelist of allowed operations, and
forbid everything else.

But I wonder how close you could get...

I think (ignoring the possibility of bugs in the JVM) you could automate part
of the generation of the whitelist.  A method is safe if and only if:

   1a) it cannot be overridden, or
   1b) it is only overridden by safe methods;
   2) it is not native[*];
   3) it does not use the facilities of sun.java.unsafe.* or any other
       JVM-level backdoor[**];
   4) it calls no other method which is not itself safe;

[*] There are several independent reasons to treat any code which touches JNI
as unsafe:
   a) JNI code is completely unregulated and can do /anything/ (e..g
      substitute its own code for any chosen class's own native methods...
   b) JNI code cannot be verified by the above algorithm, so you have to
      assume that it's unsafe.
   c) JNI code is likely to include exploitable holes (like buffer overflows,
      etc).
   d) (most importantly) ultimately, any code which /does/ anything/ is going
      to do it via JNI so this is the place to look for things which shouldn't
      be allowed, or which are susceptible to abuse.

[**] There are quite a few JVM-level backdoors, but I think most of them could
be certified safe by inspection.

Note that:

   + (1b) can only be verified by whole-program analysis unless (1a) is
      already satisfied.
   + Whole-program analysis is impossible if there is any mention of
      classloaders anywhere,
      (even in platform code, and even if restricted to platform supplied
      Classloader subclasses).
   + (4) excludes most reflective calls.
   + (4) excludes instantiating or referring to any [member of any] class
       whose <clinit> method is not safe.

At a rough guess, and assuming you whitelist System.out.println() (and
friends), you might be left with enough features to be able to certify as safe
solutions to the exercises from the first couple of chapters in a beginner's
Java book ;-)

But then, perfect security is a mirage -- there is no such thing, and even
thinking in those terms is misleading.  It would be better to consider if any
of the above techniques would usefully /improve/ the safety of the application
(bearing in mind the degree of risk involved and the costs of reducing it).

   -- chris

So, anyway it needs to call .forName() and have that reference in it.
Then, if the class, that gets loaded is in the jar-file, then it's
also under statical analysis.
If it is a foreign one, then it must be one in the classpath, and
I trust, that no class in the JRE, nor in my ext directory will
do anything nasty in it's static initializer block.

But it's a good point, anyway. Better put .forName()
onto my distrust-list, as well, even if no reflection
appears to be used.

Thanks for pointing that one out.