24

So I was doing a little research about differences (if any) between the sandboxing models for Windows 8/8.1 applications and windows 10 applications when I stumbled across something rather interesting: when Oracle shipped Java package 8 update 51 a few months they added a new feature that seems to have flown way under the radar:

New Features and Changes

Operating system's restricted environment (Native Sandbox)

JDK 8u51 introduced the following changes to Native Sandbox:

Native sandbox is available on Windows platform only.

Native sandbox can be enabled or disabled through Java Control Panel->Advanced settings->Enable the operating system's restricted environment (native sandbox) or by setting deployment.security.use.native.sandbox property to true in deployment.properties file.

Native sandbox is disabled by default.

When native sandbox is enabled, the sandbox applets or web-start applications will run in a restricted environment, that is provided by the operating system. This will not affect the all-permission applications and they will continue to run as before.

The link is here. It contains a little more (very little more) information. And trying to find documentation or discussion elsewhere has turned up ... well, basically nothing. Nothing. Were it not for that bit of text in the release notes above and the existence of the new option in the UI there would be no reason to think that a new capability had been released. Strange.

Anyway, setting aside why there's an amazing lack of information out there about this "Native Sandbox" feature, does anybody actually have any further idea of what it is, and what it does? Does it move the Java VM and libraries into the sorta-semi-sandbox "Protected Mode" privilege area that IE uses? Does in take advantage of the Windows 8/8.1 and/or Windows 10 app models to put Java VM and accompanying stuff into a new Windows application sandbox. (I know Microsoft has said that in 2016 it's going to ship a capability to put traditional desktop programs into sandboxes and distribute them through the Windows 10 store, so maybe putting Java player into a Windows 10 sandbox might not be out of the question.) Something else completely? In either case, the VM would still be there, running within the extra sandbox? I'm kinda baffled.

And why hasn't Oracle said anything about this, except (apparently) on the one single page? The feature is obviously in the product. Why is it disabled by default? Is it supposed to be in testing, somehow? Anybody?

EDIT:

Doing a slightly-different Google search turned up, ironically, a very similar question already asked on Stack Exchange by someone else but unanswered. Apologies if duplicated that question...but, does anybody know anything more about this?

Improve this question
2
  • I wont install Java myself, but check if the processes are running with different integrity levels depending on the setting used. You can check the integrity level with Process Explorer from Windows Sysinternals.
    – efr4k
    Commented Sep 23, 2015 at 12:00
  • Huh, that's a really good idea. Don't know why didn't occur to me. Will give it a go when I get home this evening and post here if I discover anything.
    – mostlyinformed
    Commented Sep 23, 2015 at 18:14

3 Answers 3

Reset to default
2

Since you sound like a Java developer then you know that Java code can modify system level things. If an applet is malicious they take advantage of this fact to try and gain access to the client system. This sort of attack is hard to stop because by the time the applet runs, it's already to late. This native sandbox is another level of protection provided by the Windows OS that makes it so that if an applet breaks out of a browser, it shouldn't be able to do anything bad since it's inside a sandbox. If it is designed to interact with the system and it gets approved to do so even if a sandbox is set, then it will be able to since then the applet would be one allowed to do this by the Exception Site List or the run time environment's Deployment Rule Set. So you could run applets in the sandbox by default with this setting just to make sure you're extra protected until Oracle decides to turn it on for everybody, but be aware that if you do this some of the ones that need to interact with the system won't work unless they get approved or you tell it to allow them too.

Disabling it by default will allow legacy applets to update and (take advantage of/prepare for) it before it gets enabled by default if Oracle chooses to do that, or if a security over conscious user wants to use a "dangerous" applet, they can do so with confidence that it won't(hopefully) ruin their system.

Currently many applets probably aren't on the ESL or many environments aren't setup to use the DRS, so by setting it disabled by default they can make sure that it won't break anything(yet). Another reason may be that this option isn't entirely supported by Windows yet, and they have their part done and Windows just needs to catch up now or they are still ironing out the details before flipping the switch. There are still many more reasons that setting it by default right now makes sense, but we won't know until they say more. My guess is they have it set off until the ESL is large enough that they feel safe in setting it on without the people who won't read patch notes asking a flood of questions about why so and so no longer works on such and such website.

Edit: After a bit more digging it turns out that the windows 10 sandbox exists already for windows store applications, info here and here, that can now be used by Java applets when correctly written and setup without problem. So it will be in the App-V sandbox used by windows store applications and newer desktop applications on Windows 10 since that seems to be the new default Windows Sandbox.

Improve this answer
7
  • Hmmm. You make a good and well-considered point, I think, about why Oracle would & could legitimately leave the setting disabled by default in the first release. Still utterly perplexed by why Oracle would say absolutely, positively nothing about the new capability anywhere but in this one release note. But ah well. Anyway, the big thing that remains unknown is what Windows sandboxing environment this is utilizing. Cause the native Windows sandboxing options ...
    – mostlyinformed
    Commented Sep 26, 2015 at 1:37
  • ...go from crappy, almost-not-worth-the-effort ("Protected Mode" low-write permissions type that was introduced in Windows Vista)to quite good (AppContainer introduced in Windows 8) to some possibilities that Microsoft might build on top of some interesting Windows 10 virtualization-based elements deep in the OS. If they could put the Java processes in AppContainer or inside some upcoming Windows 10-based virtualization layer or something while still letting it work that would actually be a pretty huge deal. But more likely it will be the super-misleadingly named Protected Mode
    – mostlyinformed
    Commented Sep 26, 2015 at 2:02
  • @halfinformed edited since it looks like it uses app-v(default win 10 sandbox)
    – Robert Mennell
    Commented Sep 26, 2015 at 19:19
  • That's a good catch. Unfortunately, the capability for desktop programs to use an App V-like sandboxing layer and be distributed via the MS talked about at Build has got delayed; hasn't made it into Windows 10 ecosystem yet. (Like at least 2 or 3 other things Microsoft has very quietly put off.) There is some possibility that the actual enabling code is in the OS now (again, wouldn't be the only half-finished feature)...
    – mostlyinformed
    Commented Sep 27, 2015 at 5:30
  • ...and Oracle is preparing the ground by getting this settings addition and/or in place early on its part. Which assumes that this setting in the Java client runtime/player will somehow interact with future App-V sandboxed applets that may (someday) be distributed via the Windows Store. Hmmm. But then would the capability that Oracle has implemented since update 51 even apply to applets like those? I suppose the capability Oracle has already put in could be adjusted, or maybe those applets still run in a browser though they came through the Store.....Hmm. Complicated possibilities.
    – mostlyinformed
    Commented Sep 27, 2015 at 5:49
1

I was curious myself so I tried to find out. These types of Java apps always run in a sandbox in the sense that they're isolated in the JVM. So, the question is what Windows support are they using. Each project seems to do this a bit differently. Here's an old page that looks at Windows user-mode, kernel-mode, sandboxing, and the Chrome model. Will teach you plenty. From there, you just update the knowledge with the security feature highlights of later Windows versions.

https://media.blackhat.com/bh-ad-10/Ridley/BlackHat-AD-2010-Ridley-Escaping-The-Sandbox-slides.pdf

All I could find for you. When I was on Windows, we mainly used Sandboxie, DefenseWall, etc for sandboxing. I'd probably try to use Microsoft's EMET and XAX, too, if I was still on the platform.

Improve this answer
3
  • 1
    Appreciate your time, and the link. Haven't seen that BH session before, and it sounds like a good review of Windows sandboxing issues. (BTW, if you ever develop for Windows again look into the new AppContainer sandboxing in Win 8 & 10 too. A neat advance.) I will def. give slides a look. Re. the question, I was sort of aiming for the idea of "What changed?" in JVM's sandboxing model with Java 8/51 vs. previous versions. Which I guess is tied up with "Does that change make Java's often-breached sandboxing any more secure?" The answers to those questions seem, strangely, very hard to find.
    – mostlyinformed
    Commented Sep 23, 2015 at 18:39
  • Regardless, it's best to not worry about it that much and just sandbox the whole thing with physical/virtual separation. A container or tiny OS + JVM in a VM should be acceptable. Might also run one like Jaos or an embedded JVM that doesn't use x86 to reduce odds shell-code will work. Just assume Oracle will get it wrong. Again. And again. And again. ;)
    – Nick P
    Commented Sep 23, 2015 at 22:57
  • 1
    Ain't that the truth. :)
    – mostlyinformed
    Commented Sep 25, 2015 at 5:18
1

So far as I can tell, that's all Oracle have released on it. It says it's only applicable to applets and web-start apps, which explains why there's so little information about it, since the browser plugin's the only part of Oracle Java that isn't open source these days. It looks like an attempt to shore up the applet sandbox using native Windows capabilities.

It shouldn't have any impact on other Java uses, such as desktop and server applications, even if they use a SecurityManager, since the code appears to be confined to the browser plugin.

Improve this answer
3
  • Yeah, I'm increasingly coming to the conclusion myself that there's just not enough information out there yet to say with any certainty how actually this uses Windows's "native sandboxing" capabilities. Which, of course, would make all the difference in whether enabling the feature could mean a huge improvement in the sandboxing effectiveness of the JVM, no real significant improvement at all, or something in between. Which, in turn, will control whether this new thing results in any real improvement to what's still one of the biggest security-headache causing products out there.
    – mostlyinformed
    Commented Sep 25, 2015 at 18:24
  • Oh, I should add that I agree that whatever "restricted environment'' in Windows this does use, from the release notes it looks like server & desktop out-of-browser applications don't get run within it. I think.
    – mostlyinformed
    Commented Sep 25, 2015 at 18:30
  • I'm almost certain that desktop and server apps aren't affected by it. I grepped the OpenJDK source for those config parameters, and found nothing, so unless it's part of the special sauce that Oracle adds to OpenJDK when compiling to Oracle JDK, it wouldn't affect anything but the browser plugin.
    – James_pic
    Commented Sep 26, 2015 at 12:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .