I recently stumbled across a problem when starting my application via JNLP. I now narrowed it down to a java.security.AccessControlException, which denies me to shut down my ExecuterService.
So, I did some reading and found out that I'll need the permission (modifyThread) to successfully shut down the service. I also found out that I should use the <security>-tag (in the JNLP-file) to request it, but I'm a little confused about how.
The documentation of the tag says:
[...] If the all-permissions element is specified, the application
will have full access to the client machine and local network. If an
application requests full access, then all JAR files must be
signed. The user will be prompted [...]
From reading this it seems to me, that I can choose to either get all or no permissions... which seems like a confusing Implementation. Because I only need the one to shutdown my service.
I also read this article, telling me that I should not request all permissions, because I would then open up the users computer for malicious code.
So, is there a way to specify that I only need the specific permission (modifyThread) and I therefor don't need to sign my jar? Or will I have to go with the "sign my jar and request everything"-approach?
..will I have to go with the "sign my jar and request everything"-approach?
Yes. JWS permissions come in 3 levels1, the only one where modifying threads is permitted, is all-permissions.
1) JWS security levels
Sand-boxed. Provides a very limited environment. Access to things like printers and the local file-system is only permitted using the JNLP API services, which provide more limited forms of File after prompting the user. Come with window banners. Can only communicate with own server.
j2ee-application-client-permissions - provide those JNLP API services unprompted (after the user accepts the digitally signed code) removes the window banners.
all-permissions - pretty much anything, including replacing the existing security manager (yes, even 'all permissions' code gets a security manager in JWS - it is just very lenient).
Also chase the links from the JNLP & JWS pages. I can personally recommend those summaries & links.
Related
My client wants to use an applet to do drag and drop file transfers from the browser. We have everything working for the most part, but the .java.policy file granting the applet file system access needs to be uploaded to every client in order for the applet to have permission to read/write to the file system.
My technical counterpart at the client has just done some research and wants me to look into the java deployment toolkit (a js library that takes care of deployment instead of using html tags). He wants me to see if I can configure the applet to use a policy file requested from a URL. I haven't been able to find how to do this, which is what I expected, since I think it would be a terrible security risk.
The trouble is that they need to be able to grant the applet read/write file system access, but I feel that requesting a policy file from a URL is a bad idea and I need help explaining why.
So that's my question: is requesting a .java.policy file from a URL even possible? If so, isn't that a terrible security risk?
So that's my question: is requesting a .java.policy file from a URL even possible?
Yes it is, but not in any way that is practical. The thing is:
The policy file needs to be in a certain location on the local file system, in order to work.
Any Java app. or applet would need trust to place it there, or even find out where the right location is.
A Java app. needs extended permissions to be able to import the policy file to where it will have an affect.
If a Java app. has the permissions to insert the policy file, it is already trusted.
If so, isn't that a terrible security risk?
Yes, it would be.
If this applet needs trust, digitally sign it.
Addendum
See Java 7 Update 21 Security Improvements in Detail for more info. on the ever tightening Java security environment.
It is apparently planned to have a future JRE default to maximum security. That would mean that by default, only classes in a Jar, digitally signed by a certificate issued by a Certification Authority (e.g. Comodo $180/year, Thawte $300/year) would ever run. Everything else would be rejected.
Why doesn't my Java Applet ask me for permission to start when I open HTML page with it on my localhost?
What is more, the applet starts but it cannot do anything. One of its duties is to connect with a webpage. But it doesn't. In console I can read:
java.security.AccessControlException: access denied (java.net.SocketPermission www.onet.pl:80 connect,resolve)
I guess there is a problem with the security settings of my Java.
It's some time since I programmed my last Applet, but I think you probably need to sign your jars.
The general policy for untrusted (i.e. not signed) applets is that they are only allowed (network-wise) to connect to the server they are loaded from. For applets loaded locally from the file system, this means they can connect localhost.
Asking the user for permission will only occur if either the applet is signed (but then the user gives permission for everything, if there is not a special security policy file) or the applet uses the JNLP functions to request some access (but this is only for local access) - for this, you would need the latest plugin (1.6.0_10 or later).
As Tom mentioned, a remote server can permit applets (and other dynamic web-content like JavaScript, Flash and so on) from other sites to access his server with a cross domain policy file. I'm not sure from which version on the Java plugin implements this, though.
Is there any way at all to use jnlp without having to sign the jars involved?
(The application is being used in a secure environment so from the security point of view signing is not necessary)
Yes you can, however the webstart application will be in 'sandbox' mode and cannot access filesystem, network and many other parts of the OS. Simply leave out the security element to accomplis this.
security Element
Each application is,
by default, run in a restricted
execution environment, similar to the
Applet sandbox. The security element
can be used to request unrestricted
access.
If the all-permissions element is
specified, the application will have
full access to the client machine and
local network. If an application
requests full access, then all JAR
files must be signed. The user will be
prompted to accept the certificate the
first time the application is
launched.
I have a non-signed java applet interacting with the same host. Every time I click on an element in my page, the applet (which is a third part applet I have no control on) should load data from a URL. I say should, because for some files, I get
java.security.AccessControlException : access denied (java.util.PropertyPermission http.agent read)
and some other files are correctly loaded. All files are correctly readable and downloadable from the web server, and they are very simple text files.
I also found that, in some cases, files that previously returned the error are now loaded and continue to load, so it seems a cache is involved somehow.
Does any of you have an idea of what's going on here ? The behavior seems to be absolutely random, and I have no way of performing debug on this thing. Note: I used this applet to perform many other "single shot" file access, and it never gave me any problem. The only apparent difference I have is that now I do it "on-demand" via a javascript event.
What could be the cause, in the java of the applet or anywhere else ?
This is a bug in the Java VM. http://bugs.sun.com/view_bug.do?bug_id=6593830 This problem seems only occur with an applet. Java Web Start seems not affected.
Some http and https URL handlers use the http.agent to set the User-Agent header.
The correct way to handle this would be to make a copy of this particular system property available whether the permission is granted or not (as with a number of others). However, what has been done is to add it on to the permissions give to applets and JNLP apps. This means that if any code is loaded through another mechanism (say a call from JavaScript over LiveConnect), it wont have the permissions and there might be a failure. If the item is already cached, then there wont be a need to write a HTTP header, and therefore the property need not be read.
The applet is broken. It is trying to access the value of a property that the sandbox security rules say that it cannot.
Report this to the supplier of the applet, and ask for a bug fix or workaround.
I'm writing a Java ME app that will use privileged operations such as messaging. By default the user is prompted to confirm each of these operations, but I would like to run it as a background service.
Documentation says to request permission in the jad file, I have done so and presume it will work on a device. However I would like to test this on the Netbeans mobility emulator first.
I tried signing the app as "trusted" but my emulated execution still prompts the user for permission.
The MIDP security model needs to be explained in 2 parts:
The phone (or the emulator) contains a security policy.
The security policy is made of several domains.
each domain defines function groups and root certificates.
a function group decides which protection options (auto agree always, user agree always, user agree once...) are available in the domain for which protected API (i.e. messaging).
The domain that applies to your MIDlet depends on which of the root certificates trusts the certificate you signed your MIDlet with.
Your problem is that there is a mismatch between what you think the protection options should be for the API you want in the domain you think your MIDlet belongs too and what is actually defined in the emulator security policy.
EDIT:
how-to for WTK-based emulators:
There are 3 _policy.txt* files in the ${netbeans_installation_folder}\mobility8\WTK2.5.2\j2mewtk_template\appdb\ folder.
They each contain a list of "alias" definitions and a list of "domain" definitions.
Make every domain have the same content as the "maximum" domain.
After this, Your emulator will never again ask for any user permission.
If you have already used the emulator contained in Netbeans, you probably want to make the same changes to the ${netbeans_installation_folder}\mobility8\WTK2.5.2\appdb\ folder.