tags:

views:

69

answers:

2

I need to create a desktop application that will run third party code, and I need to avoid the third party code from export by any way (web, clipboard, file io) informations from the application.

Somethig like:

public class MyClass {

    private String protectedData;

    public void doThirdPartyTask() {
        String unprotedtedData = unprotect(protectedData);
        ThirdPartyClass.doTask(unprotectedData);
    }

    private String unprotect(String data) {
        // ...
    }

}

class ThirdPartyClass {

    public static void doTask(String unprotectedData) {
        // Do task using unprotected data.
        // Malicious code may try to externalize the data.
    }


}

I'm reading about SecurityManager and AccessControler, but I'm still not sure what's the best approach to handle this.

What should I read about to do this implementation?

+1  A: 

A general approach would be to run your jvm with a security policy that grants java.security.AllPermission to your codebase (i.e. jar) and no permissions whatsoever to the third-party codebase. Here is some documentation on how to run with a policy file and what to put in said file.

mpm
I've read something about, but isn't the policy file passive of change by the user? So the third party developer could change the file, no?
Tom Brito
If the third party code doesn't have permission to read or write files, then no, it will not be able to change the file.
mpm
I mean the user, itself, on its operational system.
Tom Brito
+2  A: 

First of all, there is pretty much no way you can stop every information leak on a local computer. You can certainly restrict network access, and even a lot of file system access, but there is nothing that would stop the gui from popping up a dialog showing the information to the user on the screen, or any other 100 ways you could "leak" data.

Secondly, you keep talking about the policy file being changeable by the user. yes, it is. it sounds like you are basically trying to recreate DRM. I'd suggest reading up on DRM and the general futility of it. It essentially boils down to giving someone a locked box and the key to the box and telling them not to open it. If someone has physical access to your program, there is almost nothing you can do to stop them from getting data out of it, in java or pretty much any other programming language (at least, not on computers as they are built today).

james
So the SecurityManager and AccessControl are used for what?
Tom Brito
for securing code where you (the user) are running the code and you don't trust it (the code). you are trying to secure code where you (the code/programmer) don't trust the _user_, which is essentially DRM.
james
Can't I think of me as a user running code I don't trust (the third party code) and apply this tools (SecurityManager/AccessControl) for my data security? (and have a solution alternative to local policy files)
Tom Brito
Certainly you can do that. But various things you have mentioned seem to imply that someone else will be running your code, and you want to protect your data from that person.
james
If I just implement my own security manager, I can restrict all the existing permissions in JDK (http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html). I can even void the data of being shown in the screen with the AWT permissions. But I'm looking for a less hard-coded solution.
Tom Brito
If you are the user running the code, then you should be able to use a policy file to do everything you need to do in order to protect your data.
james
If you are trying to protect the data from being sent to the clipboard, that seems to me that you are trying to protect the data from the user, which you cannot do.
james
Yes, the user can do whatever he wants with its policy file. And this should not implicate in the applications information that cannot leak.
Tom Brito
If there is a permission to avoid the Clipboard access, that should means I can protect the application's data.
Tom Brito
I agree that an user with dedication may hack the system. My work is to make it as hard as possible.
Tom Brito
Again, just hardcoding your policy into your java code won't stop a determined user. if i get your app, i can decompile your java code, comment out the line which sets up the security manager, recompile the code and run it without a security manager. heck, i can run it in my own custom jvm which ignores SecurityManagers.
james
If your intent is just to stop joe-user, then a simple policy file in your apps jar will work just fine.
james
Yes, you can. And will do what I can to make it not so easy for any programmer, using a dazzling, signed, sealed jar.. And to the third party code, i need a restricted environment to run it.
Tom Brito
by the way, i don't see any permission to stop the code from displaying the data on the screen and allowing the user to cut n' paste it wherever they want.
james
Also, signing the jar doesn't affect anything i mentioned previously in terms of modifying the code.
james
see AWTPermission: http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html#AWTPermission
Tom Brito
I see that permission. none of those permissions stop code from displaying information on the screen. and the clipboard permission only applies to the _code_, not the _user_. the _code_ cannot attempt to copy data to the clipboard on its own. the _user_ may still choose to do that. remember, the permissions are there to stop malicious _code_, not malicious _users_.
james
yes, you are right. So, I need other solution than the permissions.
Tom Brito