Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / August 2007

Tip: Looking for answers? Try searching our database.

specifying revoked permissions at runtime

Thread view: 
Alexey - 15 Aug 2007 21:38 GMT
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
the game consists of writing modules that get launched into the
runtime environment and interact with a set API).  Obviously, I need
to protect the game engine from "cheating" libraries that might
somehow mess with the game engine itself or the runtime environment.
Naturally, I'm looking at the java.security framework.  I found just
the thing I need in java.lang.RuntimePermission among some other ones,
but what I'm not understanding is how to tie it to a class loader
object in a "revoke this permission" kind of way.  I'm able to grant
my own set of permissions for my own class loader, but how do I revoke
them?  It appears RuntimePermission does not rely on actions.  You can
only specify permission targets and by default, class loaders do not
include any RuntimePermission objects at all.  So it appears it's wide
open (I imagine java.* package definitions are ensured at the runtime
level, not via this security model).  One obvious thing I need to do
is restrict people loading classes within some packages because the
game engine API relies on package access protection in some places.  I
could of course inspect all jar files prior to loading them, but I
think permissions would be a more graceful and reliable way of doing
this.
Thomas Hawtin - 18 Aug 2007 00:12 GMT
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.