Yes, it would be most interesting to see the results of using a LUA with Sandboxie on 64-bit.

The fact is that merely using an LUA will stop most malware out there instantly (as in, the malware won't even start/run/execute purely because it requires administrator rights to do so). This isn't the type of malware that we should be testing with Sandboxie + LUA on 64-bit. We should be testing malware that is able to start/run/execute successfully in a LUA (while in the sandbox). Furthermore, we should then be testing if this same malware can start/run/execute successfully wtih SRP (or Applocker) enabled (while in the sandbox).

Ultimately, in my opinion, if you use Windows with a LUA + SRP (or similar) enabled, you are basically as safe as using eg. Linux Ubuntu. I suspect the reason why Linux may still arguably be safer is because there are (statistically) simply more malware writers for Windows than any other computer platform.

Don't worry. It's not like the entire world is going out to replace their working 32-bit systems with 64-bit systems. And the netbook craze is 32-bit. And most importantly, I have no reason to switch to 64-bit myself.



Yes. Remember that I'm not talking about malware getting better privileges for itself. I'm talking about a malware that might be able to restart itself outside the sandbox. Same privileges, just outside the sandbox. Now, this is not likely to happen any malware you encounter, but the possibility is there.

This is why the Drop Rights is enabled by default: Because I don't want you letting malware elevate to Administrator (because you think it's in the sandbox and safe) and then this malware restarts itself elevated outside the sandbox.

I am aware that until a couple of days ago, I was saying this is completely unacceptable and just short of the end of the world. But that is the benefit of someone standing on the outside, looking in and criticizing. Now I want "in" so it's only natural that I change the tune.

And the new tune is this: Let's suppose that in the future 10% of malware (which would be a huge number) is going to be aware of Sandboxie on 64-bit and try to restart itself outside the sandbox. So (a) you are still protected from the other 90% of malware. And (b) I can play a game of arms race with that 10% of malware.

Now from a purist perspective that might not be good enough. So for the purists there are still 32-bit operating systems, either natively on the hardware, or in the new Windows XP mode. But life is compromise and I think it's quite reasonable to compromise on 90% protection with 64-bit Sandboxie, and not consider it useless by any means.

Okay, thanks Tzuk - that answers pretty much all my questions. I too have no reason to move to 64-bit for many years to come - by that time, "Windows 8" should be out, and we may well see completely different prospects on that platform - perhaps Microsoft will go easier on that PatchGuard protection!

Unfortunately, I consider myself a purist haha. That 10% "risk" just isn't going to cut it for me! Even a 0.1% risk is not good enough! Of course, there is an element of jest in my comments there, but it's interesting to think about. It's perhaps a bit unfortunate in some ways, but I went on a journery throughout the year 2009 to find the closest thing to "100%" security, and yet maintain a "set and forget" approach. After trying out nearly all the security programs out there, I settled for a strongly configured Sandboxie in a LUA and SRP enabled. Just using Sandboxie by itself (and smartly) arguably provided "100%" protection already, so you can only imagine how powerful a Sandboxie + LUA + SRP setup is!

Because of this "curse" now (of having "100%" protection), I think I may tend to find it a little difficult to move to 64-bit, period.

Nick, while I do apprecitate your input, this question was specifically aimed at tzuk. your example is rather irrelevant because im not asking tzuk to design his program to circumvent patchguard while its running, rather its the user that can manually turn it off.

consider the following excerpt:

RSecure, would you just drop it already? It's not going to happen. When you start your own business, I want to see you throw caution to the wind and go against Microsoft. This is my business and I'm not going to risk it. Clear enough for you?

Well, more power to you then! I'm all for staying in 32-bit.

Fine ...geez , you could have said it in a less demeaning manner. What surprised me the most was your 180 degree shift from your x64 platform stance. I gues I was a little upset seeing a top notch product - "the last castle" of the antimalware soultions - become a paper tiger

Anyways if you need help getting MS to listen and provide interfaces, I'll still be glad to help out.

It isn't really going against microsoft, disabling patch guard its just a modification we make modifications, tweaks, turning off services etc on our computers all the time to make them more secure. Whats the difference? Its always the same Game with microsoft they produce a OS and we always having to make modifications to harden it.
If you make a 64 sandboxie version for patch guard disabled and If we disable patch guard on our pc's what exactly are you Risking?

What if microsoft never disables patch in any of its future operating systems or provides any help to security vendors ever? we won't be able to stay on 32bit forever so what are we going to do?

RSecure,
1. I don't know what you expect? You chose to repeatedly ignore my polite refusal.
2. Paper tiger? I don't understand. Are you under some mistaken impression that the 32-bit version is now any less secure?
3. How are you going to convince Microsoft to add more interfaces?

arran,
1. What you suggest amounts to the advocating of circumvention of built-in security measures. (Nevermind that you or I don't consider PatchGuard to be a security measure. Most people do.)
2. There are some technical drawbacks to running with a debugger present. I suggest that you configure your Windows today (whether 32-bit or 64-bit) to run with a debugger, and then let's review the issue again in a few months. You can tell me how great or how bad it was to run with a debugger attached. Sounds reasonable?

Julian I've started looking into your findings.



Couldnt reproduce any of those. Initially I didn't see any process listed other than apt itself. So I "custom added" SbieCtrl by PID. Was that how you did it too? Then I went through all the options and none affected SbieCtrl. So how can I reproduce?



Couldn't reproduce any of those, again. I tried some of those SSTS programs, but all crash. How did you get them to run in 64-bit Windows 7?



That one I could reproduce. But it's not an indication of any principle weakness. In this case, it was just a silly bug, which I fixed.



Actually, it does.

No need for images. I will update my test system to Vista SP 2 and see if I can reproduce the problem.

I ran APT sandboxed with administrator elevations. I tested with Lingoes (Of course the main executable, not the installer) http://lingoes.net/en/translator/download.htm.
Sorry, I thought that the result could be applied as general but now I see that it doesn't work with several other processes (No, Lingoes wasn't running in the sandbox. ).


I started them in XP SP3 compatibility mode and with admin elevations. Also, DEP can be a problem for some of them.



But it fails all window messages PoCs, at least when the Lingoes.exe is the target.

Thanks for your efforts.

Edit: Of course I disabled the option to restrict the rights of the administrator- and mainuser group.

So first you enable compatibility (which is another word for exclusions) for Lingoes, then you wonder how come Sandboxie allows access to Lingoes.



Thanks, I'll do that. I expect I will be able to reproduce this problem, as I remember SSTS do a lot of unhooking, and with the EndTask API no longer protected from kernel mode, I imagine that's how they manage to end programs. Let me see what I find out.

No, Lingoes wasn't started in compatibility mode, only the SSTS leaktests.

I'm curious to see the next beta versions.

I'm not deeply technical but it seems to me that the 64Bit version of Sandboxie is just a workaround where, due to popular demand, tzuk has decided to see what can be done. Basically, the situation doesn't seem to have changed from when it was said that 64Bit couldn't be supported and the reasons given why. That reason is still there whichever way the problem is looked at. I would be unhappy to use a 64Bit Sandboxie that is a compromise because of PatchGuard being in place. I also think that life without Sandboxie is risky and for that reason I'll be sticking to 32Bit.