Java Stack Introspection

Question

I was hoping that someone can help me with the following:

My understanding about java stack introspection (maybe a bit oversimplified here) is that a process generates a stack frame that is then added to the stack. Now when the process needs to make a system call the stack introspection algorithm checks to see whether the principal (i.e. the process that is trying to access a resource) is allowed to use the particular resource and then annotates the frame accordingly (granting or forbidding access).

My questions are:

1. Is the above correct or am I missing something?
2. How does the JVM decide whether to grant or restrict access? Is the user involved in this decision?
3. In this study theres an example (figure 2) in which a frame inherits/is being told the "belief set" of the previous frame! What stops malicious code from being executed in this example (i.e. get access to a resource that shouldnt have accesss to)?

Shermanshermie

@NiklasB. Its probably not an issue and I suppose it wasnt even back then but I just cant see how it works!(i.e. what prevents it from executing malicious code) – Shermanshermie

Okay, no worries :) It's an interesting question. – Olwen

The fundamental Java intra-stack security mechanism is doPrivileged. – Hegarty

Answer 1

How does the JVM decide whether to grant or restrict access? Is the user involved in this decision?

It delegates to the currently installed SecurityManager.

Is the above correct or am I missing something?

The SecurityManager can introspect on the stack, or it can use some other criteria. The SecurityManager associated with applets that run in the browser does introspect so this is right in at least one domain.

In this study theres an example (figure 2) in which a frame inherits/is being told the "belief set" of the previous frame! What stops malicious code from being executed in this example (i.e. get access to a resource that shouldnt have accesss to)?

Nothing really. Java security is a mess and many recommend turning java off in browsers since few legit sites use it these days.

"Sun Java by far the most vulnerable plug-in" from 2010.

Bright