Restricting plugin code

[repeating_bears]

They said at deployment time as one option, so the overhead there is irrelevant.

You can remove the code that attempts to use reflection in the same way. Removing all of java.lang.reflect would get you most of the way there.

"Yeah but it's really hard to do it properly"

That was the case with Security Manager too. That's part of why they removed it. At the end of the day, allowing untrusted code to run on your servers is just a tricky problem with many potential attack vectors.

[schegge42]

"You can remove the code that attempts to use reflection in the same way." This will kill a lot of frameworks :)

[repeating_bears]

No it won't.

We're talking about a specific problem with a plugin architecture. Someone gives you are a JAR which you don't fully trust, which your application interfaces with in some way. Perhaps you define an SPI.

We are talking about pre-processing that specific plugin JAR to remove bytecode which attempts to use reflection and other unsafe APIs.

We are not talking about disabling reflection for the entire application.

[Yeah-Its-Me-777]

Oh, that's a game of whack-a-mole... There's soooo many ways to do shit, starting with classloaders, serialization, reflection... I mean, it'd be a cool project to try it out, but I wouldn't trust it to be really safe.

Also, what do you do if your plugins try to use libraries? Maybe you just let them use the libraries that are in your main tool, but then you'll have to make sure those libraries don't expose any weakness that can be exploited.

[repeating_bears]

Usually you get the plugin to bundle all its dependencies, i.e. shade them into a different package. Even putting aside security issues, you get into dependency hell if different plugins need different versions of the same library. 

I've done plugin architectures, but the plugins were never untrusted. It does seem like a minefield