> I've written a prototype for an application that's going to allow 3rd
> party jar files to be loaded at runtime (it's a game, where playing
[quoted text clipped - 17 lines]
> think permissions would be a more graceful and reliable way of doing
> this.
Package injection can be stopped by specifying the packages are sealed
within the jar file manifest. Access to packages can be removed by
adding to the "package.access" security property (see
SecurityManager.checkPackageAccess). As it happens java.* packages has
special code within java.lang.ClassLoader to stop tinkering, so it is no
t a good example.
The easiest way to specify code permissions is through the security
policy file. You can also do it programmatically, as for instance
WebStart does (the source is available).
The permissions available at any point in a thread execution is the
*intersection* of all frames on the stack. That is to say all code on
the stack must have the permission in order for it to be allowed. There
are a couple caveats. Threads also inherit the stack when they are
created (so the creating stack also gets checked). Checking of the stack
can be stopped, and optionally another context inserted, using
java.security.AccessController.doPrivileged.
It's really quite difficult to get right.
Tom Hawtin
Ben Phillips - 18 Aug 2007 02:40 GMT
> The permissions available at any point in a thread execution is the
> *intersection* of all frames on the stack. That is to say all code on
[quoted text clipped - 3 lines]
> can be stopped, and optionally another context inserted, using
> java.security.AccessController.doPrivileged.
Sounds a bit like unix security, with doPrivileged like some kernel
calls or running something setuid.
There's also message passing -- an unprivileged thread might be able to
call methods that put jobs onto a queue a privileged worker thread uses.
The latter has to carefully gatekeep its privileges and guard against
misuse via malicious jobs going onto the queue.
Read up on the "confused deputy problem". Avoiding security holes in
this sort of system (where sometimes unprivileged code has to call
privileged code somehow) is a tricky art and it's very easy to get
something wrong and have a privilege escalation attack happen.
Thomas Hawtin - 18 Aug 2007 05:34 GMT
> There's also message passing -- an unprivileged thread might be able to
> call methods that put jobs onto a queue a privileged worker thread uses.
> The latter has to carefully gatekeep its privileges and guard against
> misuse via malicious jobs going onto the queue.
Oh absolutely. That is one well known avenue of attack. This is what the
inherited context in thread is about.
As a more practical example, see the source code to
java.bean.EventHandler. The context is found with
AccessController.getContext and played back with the two argument form
of AccessConstroller.doPrivileged.
Tom Hawtin