0

I am running a java app as follows and my policy file is in the same folder and it gives the following error. if I run it without specifying policy related parameters, it runs fine. any idea what I am doing wrong here and how to fix it? thanks.

Error: Could not find or load main class –Djava.security.policy==quantanywhere.policy

java -Djava.security.manager –Djava.security.policy==my.policy -jar myapp.jar

my.policy file contents:

grant {
    permission java.security.AllPermission;
};
Dan
  • 3,647
  • 5
  • 20
  • 26
Alex Santos
  • 17
  • 6
  • Check the syntax of how to specify system properties. – boneill Nov 11 '21 at 20:02
  • i got syntax from oracle docs https://docs.oracle.com/javase/tutorial/ext/security/policy.html adding codeBase with out without full path didn't help. – Alex Santos Nov 11 '21 at 20:15
  • i use the same format/order in the url you posted , as follows.. changing order doesn't make a difference : To launch the main class in a JAR file: java [options] -jar jarfile [args ...] – Alex Santos Nov 11 '21 at 21:00
  • also , i am trying to set policy for single jar , not for whole system/os – Alex Santos Nov 11 '21 at 21:02
  • at least as posted, the second `-` is not a minus, but `\u2013` - it is being used as the main class name (have you eventually copied it from some web-site?) - just retype the command using the keyboard – user16320675 Nov 11 '21 at 21:35
  • double equal is used to override existing system wide policy , single equal is used to append policy to existing system wide policy that is defined somewhere under java setup folder , neither is working on my system.. jar works fine if i didn't add -D.. portion – Alex Santos Nov 11 '21 at 21:39
  • see my last comment (is consistent with given error message; despite I cannot reproduce it on windows command line) correction I can reproduce it on Unix)- **change the 2nd `–D` to `-D` (minus D)** – user16320675 Nov 11 '21 at 21:41
  • I'll be damned. second dash (-) visually looks like what i think it is , but turned to be \u2013 as you said.. i had noticed that part in your previous comment.. replacing it with proper dash solved the problem.. that ended about 6 hours of agony.. thank you! – Alex Santos Nov 11 '21 at 21:56
  • "it is just a pixel (or half) larger" I am deeply humbled by your presence sir/madam – Alex Santos Nov 11 '21 at 22:06
  • one more question , i'm trying to stop my java app from accessing the shell using runtime.exec.. my app is scripted by embedded groovy and my users may try to use shell commands which i am trying to prevent.. i think a custom policy file is the answer but ideal way for me is to give all permissions and remove just that permission whichever it is.. can java policy file work in subtractive manner as i described or is there a better way to accomplish that? – Alex Santos Nov 11 '21 at 22:44
  • 1
    @AlexSantos working in “subtractive manner” is not supported, as it would counteract the intent of a *security* API. Every policy you didn’t care about, may potentially counteract your intent. You forbid `exec`, but not installing a different security manager? Well, easy to counter-act, isn’t it? You did forbid it, but not Reflection? Let me manipulate the field via Reflection. You did forbid Reflection as well, but not the execution of native code? Let me load a native library doing exec. You considered all that, but did not restrict file access? Let me see what `/proc/…` has to offer… – Holger Nov 12 '21 at 09:18

1 Answers1

1

i got it..

#1 create a policy file and give all permissions

grant {
    permission java.security.AllPermission "", "";
};

#2 specify that policy file in command line

-Djava.security.manager -Djava.security.policy==/path/my.policy

#3 create a custom security manager class

public class MySecurityManager extends SecurityManager
{
    @Override
    public void checkExec(String cmd) 
    {
        throw new RuntimeException( "Cannot execute shell script" );
    }
}

#4 activate your custom security manager

    SecurityManager securityManager = new MySecurityManager();
    
    System.setSecurityManager( securityManager );

#5 that's it. your app can no longer execute shell commands/scripts

Alex Santos
  • 17
  • 6
  • 1
    Step #3 and #4 are already sufficient for installing a custom `SecurityManager`. When you don’t specify any command line options, there will be no security manager at startup, hence, no security manager will prevent you from installing a custom security manager. That’s obviously much simpler than installing a default security manager just to give it a policy file that grants you all permissions. On the other hand, you could have written the denial of exec into the policy file and omit #3 and #4 instead. Of course, you should deny the installation of another security manager as well to be sure. – Holger Nov 12 '21 at 09:09
  • 2
    Another thing you should be aware of, is that [you are riding a dead horse](https://bugs.openjdk.java.net/browse/JDK-8264713). – Holger Nov 12 '21 at 09:09
  • "Step #3 and #4 are already sufficient" when i remove those , it throws security errors , first of which is not being able to access user home , probably due to initial reading from configuration file. – Alex Santos Nov 12 '21 at 19:03
  • thanks for the dead horse comment , i will look into that – Alex Santos Nov 12 '21 at 19:03
  • 1
    “Step #3 and #4 are already sufficient” means you can remove step #1 and #2, not the other way round. As said afterwards, you could achieve the same with #1 and #2 only when you use an appropriate policy file. – Holger Nov 15 '21 at 08:38