You do NOT need any other security software...

I fear that some of the emotion displayed in this thread is overwhelming some very important information for anyone to weigh.

I'm probably more sympathetic to how ErikAlbert is going about this since, frankly, that's how I approach my day job. I don't view my understanding of experimental observations as settled until I can line them up with fundamental model expectations. I've personally experienced too many instances of firm experimental data being influenced by systematically varying lurking variables which causes a completely erroneous physical picture to develop. Some systems are so complex that it's not obvious this is happening. I kind of view Windows and security in the same light. So, a detailed preimplementation analysis is useful. I hope this thread has been useful as a reality check since it is clear that there are a number of pragmatic issues that come to the front if the type of security measures discussed are implemented. But as an experimentalist, I also realize that at some point the experiment has to be run and the results tallied. That clearly is somewhat in the future in this case, so let's just take that as a given.

To try to summarize at least some of the major points raised in discussing a ShadowUser/firewall type security solution above, I would look at the following:

• Assuming the underlying applications work as advertised with absolutely no intrinsic vulnerabilities, the approach succeeds or fails on maintaining a very strict usage discipline. Lose that discipline and the approach will fail, not might fail, will fail. To me, this is the most serious issue in using this approach. I am willing to accept that it is feasible in principle, but that is a long way from workable in practice.
• ShadowUser and like minded applications often allow one to retain information between reboots. This is an intrinsic vulnerability for which no mitigating measures have been implemented in the current model. Again, user discipline comes into play. One could simply decide to have a static system which, by design, never changes and maintain that discipline of always going back to the initial state and never wavering from that point. Personally, I can't imagine being able to maintain that level of discipline and I would design in measures to account for that. At this point one is starting down the road of a "classical" solution in which SU is basically a quick restore function of the system.
• There are no in-session security measures in place. The system restart ideally cleans the system of infection, but it does not undo the history of what transpired during a compromised session. If one keeps discipline and performs no "sensitive" tasks during the session, presumably the net result is neutral - of course, one needs a very clear sense of what constitutes a "sensitive" task. I'm not sure I could fully articulate that at the moment, though there are clearly some very sensitive tasks (banking, shopping, accessing secure sites, etc.) one could list, I just am not certain where the list ends.
• While the approach is simpler if one decides to keep a machines installed state completely static, what about the case of allowing changes to be committed? Is it simpler then? How does one validate the state to be committed? A scanner? Will the new state be somehow revalidated down the road? The assumption here is that no detector is 100% certain, but will approach that over time (well, the good ones will), so revalidation is prudent.

There are certainly a large number of pragmatic details that need to be considered to make this approach work in practice.

Blue

 

What I actually did was download to a TrueCrypt volume. This does bypass the sandbox. I was in error when I tried to generalize this observation. The fact remains that the sandbox could be bypassed unintentionally.

 

I right clicked on a link and saved it to a: drive. It went straight there. If I right clicked and saved the same link to c: drive, it stayed in the sandbox.

 

Well summed up as usual Blue.

Indeed. While the risk assessment of strictly technical aspects as product by Peter2150 is important, I feel that at least for the user of shadowuser/deepfreeze, most of the uncertainty lies in the 'pragmatic details'
as Blue calls its.

Trying to predict whether someone (even if the person in question doing the assessment is the one being predicted) can hold to a certain set of behavior is a iffy one. Can you really know in advance if you can keep up to a certain regiment that you set out to do and it's a regiment that you have never done before? Can you even give a range of likelihoods? Possible but very uncertain.

I don't know about you, but i personally surprise myself a lot.

Of course even if your prediction does pan out and you are succuessful you certainly can't generalise it to the average user at large particularly as Blue says succuess of the method is highly contingent on the user more so than classical methods.

It's not a unique problem, Perhaps what i dubb as 'first generation HIPS' (behavior blockers with no whitelists or centralised databases) share part of the same problem with their succuess being largely contingent on the user reacting correctly to prompt.

Altough as i argued above, in many cases, predicting user reaction to HIPS is easier as compared to shadowuser/deepfreeze because the former is a closer model to standard scanners while the later is a fundmental new way of working.

If any good has come out of this discussion about merely 'theory' adavanatges i think it shows that perhaps, we have being traditionally too concerned with only technical issues (Is there a zero day buffer flow exploit that can beat VMware? What is the score of KAV on AVtest.org? Can online armor beat the WMF exploit? ) when we start discussing the pros and cons of security software while tactly underestimating other merely 'pragmatic' issues (how easy is it to use? how noisy is it?) and consign it merely to the background.

Perhaps our familarity with scanners (coverage/packers/frequently of updates etc) and lesser degree HIPS (what areas is covered, polling versus hooking , kernel versus user mode etc)allows us to quickly articulate a list of technical indicators that we quickly look at. And these take CENTER STAGE!

But this tendency stumbles when we talk about shadowuser and deepfreeze, relatively newer and rarer types of software, with new models of usuage, in which we still haven't figured out a quick way to compare them technically. No wonder, the pragamatics suddenly take the centre stage. And rightfully so, for such a class of software.

Erikalbert's continual demand to show what the weaknesses of his approach by theory only, was I think interpreted by him and many ohers in the merely technical sense.

With people showing rare exotic attacks (Peter2150's last proposal was in this tradition), which I think missed the point. Though such weaknesses might exist, I would agree with Blue's analysis that even if they didn't the main bar is not a technical issue, but a social/user issue.

Sadly that is an issue that can be settled only on a per user basis, and in any case cannot be settled by merely a battle of words on this forum.

Practical experiment is what will decide the outcome of Erikalbert's experiement not empty arguments about the likelihood of theory attacks. Sadly we won't know the outcome until middle 2006.

 

TrueCrypt works as a kernel driver, so this hardly comes as very surprising.

http://img235.imageshack.us/img235/6169/immagine4ai.gif

It's not a flaw in Sandboxie. The fact that TrueCrypt bypasses it is that it works with higher privileges already outside the sandbox. TrueCrypt wouldn't be able to reach outside the sandbox if you started it inside the sandbox without it working already at kernel/driver level (in fact, Truecrypt can't work in the sandbox at all).

 

I didn't say it was a flaw. But semantics aside, if something got passed the sandbox, it got passed the sandbox. I'm aware that it happens and I've adjusted my behavior. I think I'm smart enough to spot these situations as they arise. Point is, SandboxIE is not bulletproof.

My next post, I said I downloaded straight into a: drive from my sandboxed browser, bypassing the sandbox. I don't have a usb memory stick, but I wouldn't be surprised if that happens if I downloaded something straight there too. That's a physical limitation that I gather is difficult to overcome. But again, it's something you need to be aware of.

The main thing I was trying to say in my original post was that these things wouldn't be apparent if I hadn't actually installed the program and used it. SandboxIE is a great prog, imo, but there's still discipline involved. You can't be an "ignorant user" and expect the software to save your butt everytime. That goes for whatever your security philosophy is.

 

Ok.
Sandboxie indeed does not work with the floppy drive. Not sure why this was implemented that way. But it does work for hard disk drives other than C: (they appear as "HarddiskVolume1", "HarddiskVolume2", etc).

I absolutely agree on that one.

 

That's good to know. But, of course, I have to see for myself.

 

Good grief. I just went to their website to look at that ShadowUser program for the first time ... that thingie is $70. It had better be good!!

Acadia

 

Acadia, how much is the FDISR that you use? They are very similar programs.

 

I just looked at the FDISR site and Raxco sells the download version for $69.95.
http://www.raxco.com/products/commerce/purchase_options.cfm?ItemTitleId=52

 

Good grief, is it that much now?! (Or is my memory now that bad )

Acadia

 

Ok, my memory is not all THAT bad, I paid $47 for it a year and a half ago, in cd form from CDW.

Acadia

 

Hmmm, Raxco has it at their website for just $38 in cd form.

Acadia

 

I never imagined my thread would become such a huge discussion and argument. Yeah but really nobody should ever think that SU alone is enough. I somehow got sort of brainwashed a bit by ErikAlbert, thanks to his strong promotion of SU. SU alone is not enough if you consider this: What happens during the virtual session can be very dangerous too just as in the physical session. Its plain common sense, use a layered approach to securing your system.
And I think the saying that no security product is 100% foolproof applies to this method of sandboxing a system as well. How 'bout working for Shadowstor if you love their products so much?

If you take the advice that Shadowuser alone is more than enough, then I say you are wrong and an extreme risk-taker.

 

I do not think ShadowUser alone is good enough either. More generally, a single security software is never the approach. 1) Every software has flaws, and has the chances to be broken through. The system would be totally naked if the only security software is broken through. 2) We, the users, never know what's under the hood of a security software, i.e. how the security is implemented at the code level. Who knows what really happens there? Maybe there is a backdoor in the software for some purpose. If several security software used together, at least they can guard against each other.

 

Shadowuser along with something like anti-executable plus a hardware and software firewall is enough in my opinion. In fact, it's better than some of the long lists of software used by many.