Is there anyway to restrict the permissions a signed JNLP/JWS application receives?
For testing this I wrote a little app that, with a button click, can create, read, write to, and delete a file.
With the unsigned version I get an AccessControlException, as expected, while with the signed version I can do all tasks.
Then I first added the following policy to the javaws.policy file, but without any effect:
So I added it to the java.policy file, but this also doesn't have any effect.
Is this at all possible? If so, how can I accomplish this?
Today I closely examined the specification (jsr-56), the first section of paragraph 5.6 reads:
This specification specifies two trusted environments, the all-permissions environment and an
environment that meets the security specifications of the J2EE Application Client environment. Both of
these environments provide unrestricted access to the network and local disk. Thus, an application can
intentionally or unintentionally harm the local system. An application must only be launched if it is
Is there no way whatsoever to restrict this somewhat?
Thanks Maneesh for your answer, I really appreciate it.
Its indeed the code I want to restrict access for.
With JWP you download applications from the internet of which, signed or not, you don't really know what its doing, nor where its coming from.
That's why we want to restrict the permissions for the application to a certain degree, the application must be able to do its job, but nothing else.
Being an architect I'd like to come up with a standard way for our company to restrict the permissions 3rd party applications get to a predefined set.
Yesterday I found out that it is possible to restrict permissions if the JWP application's jnlp file does not specify the <all-permissions/>.
It appeared that the permissions defined in the javaws.policy are effective then.
But it would be best if this would also work with security settings enabled in the JNLP.
I personally have never used the policy file approach. Would the user who logs in to the machine be able to edit the policy files?
In the past, when I have worked with customers from the Banking domain, or domains where security is paramount, I have observed that they implement a centralized rollout/deployment model, where the IT admin team would remotely deploy only authorized applications onto the workstations.
You might want to consider that .
Another idea would be the IT guys to examine the jar using probably reflection. Probably the jar can be scrutinized for known API/objects. e.g. if URLConnection is used, then the jar probably makes a server side call. If File is used, then it can possibly access the file system. I am not saying this is fool proof but I feel some analytical and flagger kind of tool can be developed on those lines.
Joined: Nov 07, 2007
It depends on the users local rights whether or not he/she can edit policy files. Users with Local Admin rights obviously can.
We have a centralized rollout model, thanks for that suggestion, but there are different profiles for installation. JWS/JNLP conceptually seems to be an interesting alternative, therefore am I investigating manners to control the permissions these applications can get.
So far these are the alternatives:
all-permissions, runs in the trusted environment, no influence on granted permissions
unsecured, runs in the untrusted environment, full influence on granted permissions through the javaws.policy
write our JWS launcher that forces certain pre-defined policies onto JWS applications
The latter gives the greatest flexibility, but also requires us to roll-out a modified JRE to each workstation and maintain the launcher.
Examining the jars, IMHO, only reveals the possible actions required by the application, not the location. E.g. accessing a file on the local system may be permitted in certain locations, but denied in others.
You have summed it up nicely. Thanks.
The problem you are trying to solve is interesting and I would be very much curious to know which option you pursue in the end. It would be nice if you can share the approach (not the code mind you) with us.