specifying revoked permissions at runtime

Discussion in 'Java' started by Alexey, Aug 15, 2007.

  1. Alexey

    Alexey Guest

    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.
    Alexey, Aug 15, 2007
    #1
    1. Advertising

  2. Alexey wrote:
    > 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.


    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
    Thomas Hawtin, Aug 18, 2007
    #2
    1. Advertising

  3. Alexey

    Ben Phillips Guest

    Thomas Hawtin wrote:
    > 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.


    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.
    Ben Phillips, Aug 18, 2007
    #3
  4. Ben Phillips wrote:
    >
    > 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
    Thomas Hawtin, Aug 18, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Scott Allen
    Replies:
    0
    Views:
    421
    Scott Allen
    Jul 13, 2004
  2. Isabelle
    Replies:
    0
    Views:
    551
    Isabelle
    Aug 11, 2004
  3. Scott Edward Skinner

    Multiple JVMs; specifying the runtime lib

    Scott Edward Skinner, Sep 15, 2004, in forum: Java
    Replies:
    11
    Views:
    3,117
    Andrew Thompson
    Sep 19, 2004
  4. Maciej
    Replies:
    5
    Views:
    361
    Chris Uppal
    May 31, 2006
  5. Curt K
    Replies:
    0
    Views:
    548
    Curt K
    Nov 3, 2006
Loading...

Share This Page