I'd like to specify certain applets to run with java.security.AllPermission on my computer (for debugging and security testing). However, I don't want to enable all applets that I run to have this permission. So, editing my user Java policy file (which I have ensured is the correct policy file through testing), I try to put this value:
grant codeBase "http://host_where_applet_lives/-" {
permission java.security.AllPermission;
};
This value fails when the applet tries to do something powerful (create a new Thread, in my case). However, when I put the following value:
grant {
permission java.security.AllPermission;
};
The applet is able to perform the powerful operation. The only difference is the lack of a codeBase attribute.
An answer to a similar question asked here [1] seemed to suggest (but never show or prove) that AccessController.doPrivileged() calls may be required. To me, this sounds wrong as I don't need that call when I grant the permissions to all applets (the second example I showed). Even if this is a solution, littering the applets I run with AccessController.doPrivileged() calls is not easy or necessarily possible. To top it off, my tests show that this just doesn't work anyway. But I'm happy to hear more ideas around it.
[1] Can't get AllPermission configured for intranet applet. Can anyone help?
The answer to the similar question you referenced suggests that calling Java applet code from JavaScript may lead to a SecurityException because the AccessController will do a stack inspection and fail because of the untrusted JavaScript. I tried out the code and sure enough, Firefox won't run the applet called by JavaScript without a doPrivileged() call but Safari will (at least on Mac OSX).
If you are calling your applet from JavaScript, you could try using the Applet.paint() method instead to automatically invoke your applet. Or, you could use the doPrivileged() method to short-circuit the stack inspection, and give yourself whatever privilege you need. Of course, then any untrusted code would be able to call into your privileged code.
Related
What you do to get rid of this? I wanted to make a game that is accessible from browser. Then I get error "Your security settings have blocked a local application from running".
I changed browser. nothing.
I added exception in "configure java". Nothing.
I looked internet and looked for "medium" security level but it was removed..
Honestly, I'm not sure. But, I might know what's causing the problem. I'll list most of them here (you can find the full list at What Applets Can and Cannot Do):
Applets cannot access the local file system.
Applets cannot connect to or retrieve resources from a third party server.
Applets cannot load native libraries.
Applets cannot change the SecurityManager.
Applets cannot create a ClassLoader.
Applets cannot read certain system properties.
In summary, don't try to make changes to the user's desktop or the client's windows folder. Have them upload the file instead. Don't try to access .pngs or .json from external servers like google or yahoo either, probably because java can't guarantee them to be safe too. Neither can you load native libraries, so you might want to avoid those if you can, and finally you don't have access to some info in SecurityManager, ClassLoader or some System Props.
If your app violates one of these, Java is likely blocking your app from running. But it all depends on your implementation too. Make sure your browser doesn't block certain applet features (and that java supports your browser, make sure everything is enabled too) and try again.
Or, you can ignore all of that and try making your app privileged. Unfortunately I have very little experience with the process of making your app privileged, but from what I can hear, it'll give your applet a little more room to move in.
Thanks to Oracle's latest changes, it appears I have to sign an applet even though I don't need or want it to have unrestricted access to the user's computer (which is why its currently unsigned). In particular, I don't want the warning they show for signed applets:
This application will run with unrestricted access which may put your computer and personal information at risk.
...which will scare the people using it.
Is it possible to sign an applet but mark it in some way to say "but keep using the sandbox"?
The only reason I'm signing it is that as of Version 7, Update 40, Oracle has further increased the nagging users have to deal with when running unsigned applets. It used to be that you could check a box saying you trusted an applet once, and that would be remembered. As of Update 40, it's only remembered for that browser session; the warning reappears if you close the browser and come back later. They've also said they're going to disable unsigned applets entirely in "a future version" of the Java plug-in.
Yes, you can. This page shows how to do it (well, most of it; you also need this page). There are two main steps:
Put the Permissions and Codebase attributes in your manifest file:
Permissions: sandbox
Codebase: *.myserver.com
These new attributes were introduced in Java 7 Update 25 and are discussed here. The first page linked above just shows Codebase: myserver.com, but most sites are going to want the wildcard above. (I don't know if the Codebase attribute is required for sandboxing the applet, but it seems like a good idea for most signed applets anyway.)
Then use that manifest file when building your jar, like:
jar cvfm YourJarFile.jar your_manifest_file.txt classes_and_such
Those attributes will wind up in the MANIFEST.MF file in the jar, which tells the Java runtime to keep the applet sandboxed.
In your <applet> tag, you have to specify the permissions param, as discussed here:
<applet code='yourAppletClass' archive='YourJarFile.jar'>
<param name="permissions" value="sandbox">
</applet>
Without this second step, a signed applet requesting sandboxed permissions in the jar but not the tag is prevented from being run with a dialog box titled "The Application Cannot Be Run" giving "Reason: JAR manifest requested to run in sandbox only."
If you do both steps above, the user gets a much more reassuring message (and presumably the applet remains sandboxed):
This application will run with limited access that is intended to protect your computer and personal information.
...and if they check the relevant checkbox trusting the publisher and location, they don't see it again when they next open their browser and run your applet.
(In the course of asking this question, I found the answer, but since the answer wasn't on Stack Overflow I thought I'd go ahead and post the question and answer.)
I'm trying to use the new Java 7 Files.createSymbolicLink() method within Play! Framework, and I got the following exception:
RuntimeException occured : java.nio.file.FileSystemException: c:\work\foo\bar:
A required privilege is not held by the client.
This is my first encounter with Java's permission model, so I understand what's going on, but don't yet know how to fix it (I'd like to give the Controllers more permissions).
If anyone can answer here faster than I'll find the answer, me (and future readers) will be grateful.
This isn't a problem with java permissions, but a problem with the operating system permissions. See FileSystemException.
The subclasses of FileSystemException are: AccessDeniedException, AtomicMoveNotSupportedException, DirectoryNotEmptyException, FileAlreadyExistsException, FileSystemLoopException, NoSuchFileException, NotDirectoryException, NotLinkException.
From AccessDeniedException:
Checked exception thrown when a file system operation is denied, typically due to a file permission or other access check.
This exception is not related to the AccessControlException or SecurityException thrown by access controllers or security managers when access to a file is denied.
After seeing this answer, and remembering I am running on Windows 7 with UAC, I understand this is a Windows issue.
Nothing can be done from within Java to make this go away.
I should be able to turn off UAC for Play specifically somehow (run as admin etc...), but the question isn't really related to Play (or java permissions) at all.
Indeed, when running:
runas /noprofile /user:Administrator cmd
cd c:\myapp
play run
everything works well.
I need to use the systemRoot feature of the Preferences API, but it fails due to lack of permissions on Windows if UAC is on. I'm trying to find the technical details of popping the UAC prompt and elevating my permissions to allow the systemRoot updates to succeed.
According the accepted answer to this SO question, you cannot change the UAC permissions of a running process.
According to the answers to this SO question, possible ways to launch a process with elevated permissions are:
create a wrapper to launch the JVM (with the appropriate arguments!) with a windows manifest that requests raised privileges, or
use the application linked to the 2nd answer to run the JVM with raised privileges.
In addition to the manifest Using JNI to call ShellExecute with verb = runas will also do this - but specifying things with a manifest is a more robust way of doing it. Getting a manifest embedded in an exe can be a bit tricky, and there were a lot of problems with manifest handling in earlier versions of Visual C++, but most of them are worked out now.
That said, I'd encourage you to think hard about why you need to access the system root - is it to store settings for all users? If so, you may want to consider having a separate application for managing those settings (with it's own manifest). You can't just pop open a UAC elevation dialog - you actually have to launch a new process (if you look at task manager with apps that appear to work this way, you'll see that a second instance of the app actually gets launched - look at the UAC Virtualization column in task manager to see the differences).
Another possibility is to adjust the security settings in the area of the registry that you absolutely must configure from your non-elevated process - but this goes against the design of UAC, and it'll almost always cause more trouble than it's worth. Probably better to drink the M$ kool-aid and design your app properly for UAC. (Believe me, I feel your pain on this - been through it a number of times).
As I was experiencing this pain myself, I found the following MSDN article quite helpful to understand the Microsoft design intent with UAC:
http://msdn.microsoft.com/en-us/library/aa511445.aspx
Hope this helps...
You can use run-as-root library: https://github.com/dyorgio/run-as-root
// Specify JVM options (optional)
RootExecutor rootExecutor = new RootExecutor("-Xmx64m");
// Execute privileged action
rootExecutor.run(() -> System.out.println("Call your admin code here."));
P.S.: I'm the author.
I have a Java applet which sometimes throws a java.security.AccessControlException whenever I call File.exists(). The problem goes away whenever I enclose the operation in an AccessController.doPrivileged() block. However, I can't figure out why. My applet is signed and should be fully trusted. In other scenarios, it can read/write to files without any problems.
Is there a way to walk up my calling stack and examine the effective permissions so that I can see who or what is trusted/untrusted?
You should enable java.security.debug property with access:stack first. It will help you understand what permission is lacking to the domain.