tags:

views:

104

answers:

4

Can I avoid third party code from creating new threads, starting new VMs, or leaking data using a customized SecurityManager?

+1  A: 

No. (some characters)

Tom Hawtin - tackline
-1 (some characters)
Rook
@The Rock -1? Is my answer wrong?
Tom Hawtin - tackline
@Tom: it's "not useful", which is what the tooltip of the downvote arrow states.
Joachim Sauer
@The Rock Not useful? It's **the** answer to the question.
Tom Hawtin - tackline
The "not useful" comment was from me. The reason this answer is not useful is because it doesn't state *why* a `SecurityManager` is not a full solution, when it clearly looks like it should be. (Also: the question contains more than just the title).
Joachim Sauer
It was never asked for *why* the SecurityManager is not a full solution. It’s not (the one) Tom’s fault that (the other) Tom does not know what question he *really* wants to have answered.
Bombe
@Bombe: taking questions extremely literally is what gives IT experts a bad name. Or are you trying to say that you *didn't know* that (the other) Tom might want to know reasons for a "No" answer as well?
Joachim Sauer
Joachim, I have no idea what he really wants besides for what he says he wants. I’m a programmer. *Tell me* what you need, don’t make me make assumptions. It’s the same thing with questions. Stack Overflow is for programmers and—and this is the only assumption I make—programmers *have* to be able to explain *exactly* what they need. Otherwise they shouldn’t be coding at all.
Bombe
+2  A: 

You can certainly do the first two things. However, i'm not sure what you mean by "leaking data".

Note, you don't need a customized SecurityManager, you just need a custom policy file.

james
But isn't the policy file passive of modifications by the final user?
Tom Brito
I don't really understand what that question means.
james
+3  A: 

Thread creation results in a call to securityManager.checkAccess(g) where g is a ThreadGroup. That in turn requires SecurityConstants.MODIFY_THREADGROUP_PERMISSION.

The only way to create a new JVM instance is to start a new process. That will require SecurityConstraints.FILE_EXECUTE_ACTION.

So, if your SecurityManager raises an exception for both of those permissions, your first 2 cases are covered.

You'll need to qualify what constitutes "leaking data". Is the concern over accidental or deliberate leaks? Is the concern the untrusted code accessing data, or the untrusted code's data being accessible by other threads, classes, etc?

Devon_C_Miller
+2  A: 

Nothing much is a full security solution (unless you ask salesmen).

I'd say the SecurityManager can control all this (as was said you don't necessarily need a custom security manager, you can configure a lot simply through a policy). Controlling threads, process execution, enforcing access to private data and network connections (3rd party app sending private data to your competition, etc) - that's what the SecurityManager is for.

However, you need to weigh how much security you need. Consider that with every Java security update Sun fixes maybe 3-4 vulnerabilities (Java 6u15 as an example) in the Java security sandbox. These updates take place about 3-4 times per year (or took, don't know what the Oracle acquisition will do to that). So any of these ~12 annual vulnerabilities could cause your data to be leaked.

If my secrets were very valuable to someone else, I personally would not trust SecurityManager to control potentially malicious 3rd party code running in my environment. (I don't have valuable secrets and I already don't trust Java running in my browser under the SecurityManager to behave.)

Sami Koivu
The original question said "export" rather than "leak". This seems to imply that the issue is whether untrusted code can publish data it has access to externally. As it turns out, getting rid of all covert channels on the internet is a little tricky.
Tom Hawtin - tackline
I see. Reading that and the other questions by (the other) Tom. If he's worried about the final user altering the policy file, I may have misunderstood his scenario.
Sami Koivu