proglang / jgs Goto Github PK

Currently, jdeps reports the following dependencies when instrumenting a single-class app:

~/opt/openjdk8/bin/jdeps DynamicAnalyzer/main/testclasses/AccessFieldsOfObjectsFail.jar | grep 'not found' | sort | uniq
-> org.apache.commons.cli not found
-> org.apache.tools.ant not found
-> org.apache.tools.ant.taskdefs not found
-> org.apache.tools.ant.types not found
-> org.junit not found
-> org.junit.runner not found
-> org.junit.runners not found
-> scala.collection.convert not found
-> scala.collection.generic not found
-> scala.collection.immutable not found
-> scala.collection.mutable not found
-> scala.collection not found
-> scala.math not found
-> scala not found
-> scala.reflect not found
-> scala.runtime not found
-> scala.util not found
-> soot.jimple not found
-> soot not found
-> soot.toolkits.graph not found
-> soot.util not found

We should not need or require those.

See http://stackoverflow.com/questions/12703500/is-it-possible-to-use-the-soot-analyses-without-calling-soot-main-main

This way, we might be able to handle exception during a series of soot analyses.

Currently the logger is too noisy. What should be logged? At what level?

stands for JGS RuntTime. It should contain everything currently in DynamicAnalyzer/analyzer/level2/*
plus some code to load a custom security domain.

see utils.ant.build.xml

Currently, comparing jimple from original and instrumented code, the local variables are named differently... that is annoying during debugging

For generated instrumentation code, we currently use some temporary local variables, e.g., "local_for_string". There are some problems with this approach:

1. we have to distinguish instrumentation variables, generated by us, and regular variables. The latter have their security levels tracked, the former do not. Currently the distinction is buggy as it just checks for the special names (e.g., "local_for_string") and does not check for name collisions
2. a prominent use of these variables is for passing constants to methods involved in instrumentation. We should pass constants directly, instead (more efficient, less awkward code)

There are some typos and unfortunate wording in logs and error messages. (I don't remember the exact places atm)

Currently they are longs, String and ints in different parts of the code. (Ints are enough as a method cannot have more than 2^16 statements)

Some methods take such a parameter. It has no place there.

Three points:

1. Running the program (main.Main) without arguments gives an ArrayIndexOutOfBoundsException. The cause is an unguarded array access in ArgParser.getSootOptions. The integrity of the command line arguments should be checked beforhand and a proper error should be reported, in addition to a usage message.
2. The order of command line arguments matters. It shouldn't.
3. Running the program with '--help' yields an IllegalArgumentException. It should show the useage info

currently, ANT uses build.xml and build.properties to build JARs. Two issues arise:

• jgs needs to write build.properties for every ANT => we don't want that we need to have write access to execute our program.
• currently, all paths are relative to "user.dir". Better use paths relative to classpath. Maybe ClassLoader.getSystemResourceAsStream("")

Currently we set Soot's classpath to that of the JVM by taking the URLs out of the current UrlClassloader. This seems messy and, at least in the case of sbt, does not work reliably.

After 837d0f3, DA should be able to handle polymorphic methods, i.e. methods
where some parameters or return types may be dynamic or static, depending how
the method is called.

This support is purely dynamic, that is, we do not generate specialized methods.
It works by (i) treating polymorphic parameters and return values as dynamic
during instrumentation, and (ii) introducing the notion of tracked and
untracked variables:

• Static or public variables are always untracked.
• Dynamic variables are tracked if they where set by dynamic sources.
• Dynamic variables can be untracked, if their value depends only on untracked sources.

An untracked variable can flow to tracked variables and pcs. Gradual security
typing implies that the variables is public in this case, so DA ignores
untracked variables in joins and NSU checks. Tracked variables, in turn, should
never flow to untracked variables or pcs, except by using a cast.

What does this strategy imply for polymorphic methods? By ignoring untracked variables, DA can now do dynamic checks and
join-operations on labels everywhere; before, it required a level being present.So calling a polymorphic method with
static/public arguments would just result in tracking overhead, but not lead to
security error. And conversely, calling a polymorphic method with dynamic, i.e.
tracked, arguments just works as before.

... and now we need to test this approach thoroughly.

Special methods are those in "ExternalClasses". My guess is, they are ignored by erasure (or worse). They should not be.

preliminary code, commented, is in analyzer.level2.SecurityLeve.java

... for example we can map which strings encode which variable for HandleStmt with an Annotation on the variable

One seems to be for compile-time logging, the other for run-time log-messages. They do mostly the same thing and should be unified

Currently we cannot run on windows. Probably because incompatible path/file conventions that we hard-code

Currently we emit a jar containing the instrumented program. This is suboptimal, as we cannot test the final result w/ Junit well (ant does not allow to execute jars without forking the vm, and with forking we cannot check thrown exception reliably).

So before building a jar, we should write the content to a designated output directory. We can test the final output by setting the classpath to the output directory during testing.

currently, it is always enabled

So we can define expected outcomes in a single source file (instead of in an AllTests.java)

With moderate effort, we could implement a simple type inference scheme that would allow to leave of the annotations of non-recursive methods

• collect a map of method calls G : Method \to P(Method)
• check for cycles in the call graph induces by G, also taking virtual calls into account (could be refined, later using a "properly analyzed" call graph)
• if there are cycle, complain that we need more annotations
• otherwise topologically sort G and start inferring types starting from the leafs.

Factor into lhsSwitch and rhsSwitch. Most cases should be disjoint (but this needs to be checked)

instead the user should provide a name as a command line argument

... cause that what it does.

.. by calculating the variable ids to be joined on the rhs and then generating a HandleStmt call that joins exactly those variables.

The testclasses is what we use for the e2e-tests. Example should go somewhere else

Not trivial... some interfaces seem to have changed