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?
Thanks for your time and help.
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?
Sure hope anyone here has some insights in this.
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.
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.
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:
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.
Thanks for the feedback,