MQP:A Thread Example
Contents |
|
Analyzing Calls to Thread.start()
This section describes how Koved's method for handling Thread.run() invocations in security call graphs can apply to different subclasses of Thread.
Analyzing security information about permissions required when Thread.start() is called is a bit different from a normal method invocation. The start() method is being invoked on some Thread object, or an object that is a subclass of Thread, and this object may not have been created in the current security context. The run() method specified by the object (whether the run() method is actually overridden or through use of a Runnable passed to the Thread constructor) represents code that should be executed in the context of that created the Thread, not the context that calls Thread.start().
For this reason, it is not appropriate to traverse normally back through Thread.run() to the method that invoked Thread.start(). Instead, the correct behavior is to traverse back to the constructor of the type of Thread in question, which will in turn lead to each method that instantiated a Thread of that type.
In the following diagram, we model the behavior of a program that is creating two different types of Threads, a MyThread and a WorkerThread. The dotted lines represent implicit calls to Thread.run() through Thread.start(), which is not shown (this is the way that Soot models this type of call in its call graph, and is convenient for our purposes). The nodes that are red require the permission from MyThread.run(), the nodes that are blue require the permission from WorkerThread.run(). The purple node requires both types of permissions, since it instantiated both types of Thread. The red and blue edges represent the new edges that would be traversed in the call graph as a result of using this method. The black nodes require no additional permissions from the calls to the run() methods.
