Is Applocker really that good??

It is a matter of 'zero benefit' - I was quoting him saying that.

Not sure what you're saying here. How?

As with all things there is a tradeoff. You weight the benefit of introducing potential attack surface when you use Sandboxie. Just as you should be weighing the benefits of introducing potential attack surface when you open IPC to EMET.

If you think Sandboxie is indestructible, the perfect panacea of policy, sure - by all means disable DEP, ASLR, SEHOP and rely entirely on it.

 

The more I look at AppLocker, I'm convinced it's more an IT tool to restrict "users" from using the apps, as HungryMan put it, and not the apps themselves. As a single user it's not nearly as useful to me, and isn't what I'm looking for. I believe a tool like EMET, or GP tweaks, SRP, etc... can all accomplish what I'm looking to do better. Not to mention Sandboxie.

But really... an integrated HIPS akin to D+ would be awesome.

I haven't closed the book on this issue yet. It'll still be 2+ years till I upgrade, so still plenty of time to flip-flop.

 

I was actually giving my own opinion about being a benefit or not.

Simple, no? I explained why. And, if you understand Sandboxie's concept, then you know EMET is futile inside the sandbox, and simply because Sandboxie is already meant to stop the malicious code from running in the user's system, or give the user a clean sandbox, provided he/she cleans it.

Quite true, it's a tradeoff. Sandboxie is a program with its fair shair of bugs, just like any other application, I'm sure of that.

And, like any other program, we expect its developer to do a good job and promptly fix any issues with it.

But, I didn't really brought to discussion whether or not Sandboxie itself would pose a risk, at some point in time. Otherwise, we'd go around in circles, becaus everything poses a risk to the user, including security software. lol

This discussion's point is about opening holes in Sandboxie. If you start opening holes in Sandboxie to allow IPC with every possible application you got in your system, then there's really no point in having Sandboxie, at all. Why installing a security software that's suppose to isolate the sandboxed system from the real system, when you open holes in it?

I'm not sure I understand this comment? Those are native mitigations. They're part of the system. Anyway, regarding EMET, I use it outside of the sandboxes.

Do I think Sandboxie is indestructible? No, I don't think that. The perfect panacea of policy? No, I don't think that either.

What do I think? I know that if you start opening holes in the sandboxes for each possible combination of convenience, for sure you're weakening Sandboxie. And, the more convenience the weaker it becomes.

Now, if you believe that adding all this convenience far outweighs the risk, by all means create those holes.

 

This is a very good point, and one I brought up previously. So is it worth it to add an exception in Sandboxie for something like EMET? Worth the tradeoff? I guess that's up to the individual user to decide.

I personally don't like the idea of any exceptions/direct access. I would feel safer knowing I'm fully isolated. I think I may just use those mitigation techniques for essential Windows processes only, and not add apps to the list. At least not any I run sandboxed. Probably make for a lighter system, and less chance of conflicts too.

Again, I have plenty of time to waffle on this.

I have a few sandboxes for Firefox. In one I allow direct access to bookmarks, and compatibility for things (i.e. Keyscrambler).

In my lightest ruled one, also things like PDF reader, media player, ect...

In my most secure box... none of the above. Full isolation. And I use this if I'm ever doing something considered sensitive.

 

Then I misunderstood.

I think I understand Sandboxie's concept just fine. Create a virtualized file system for applications to isolate them from the system while maintaining compatibility - it's great. But how does it somehow mean EMET doesn't do anything? I don't understand what's futile about the protections.

At this point I expect quite the opposite, sadly. But I see your point.

But... all you have to do is open IPC to EMET. So what's the issue?

And I'm not saying to start opening a ton of holes (though I think users should if it makes things more convenient, that's just me) but only to open the one hole to EMET. That if you open that hole to EMET the potential benefits outweigh the potential risks.

The comment earlier by Melf was that there are no benefits to using EMET if you also use Sandboxie, which I disagree with.

Once the application is on the system the attacker can still do a lot. They can potentially bypass Sandboxie - so preventing them from getting on the system with something like EMET provides value.

 

It can be used that way, and is certainly an IT approach method for using it. However, it will also restrict anything unauthorized from running, and that includes single file (user space) executables, scripts and DLL's, so it's far more beneficial than just restricting known applications from specific users. Indeed, you are right HIPS tend to offer far more granularity in terms of how an application is allowed to run, but I feel this is usually unnecessary, and the additional control and complexity of a typical HIPS is not only overkill but causes more grief than benefit to most users. AppLocker and SRP are simple but elegantly effective - Allow or Deny.

 

Also from what I hear HIPS implementation is flawed in Win7. Or is it only the 64 bit version? So this may be the only viable option I've got.

I wonder really too, how much lighter the Pro version would feel than Ultimate, on a box with 12 gigs of RAM? Would I even notice it at all? If not, I may as well just go with Ultimate. Because the money isn't an issue at all. The issue is that I'm anal about resource usage and streamlining.

 

I would, and have. Not perfect, but definately good enough right now.

AppLocker is SRP2. It is very similar in many respects, it has merely been expanded and improved. I think you are correct though, that the underlying principle is the same, just AppLocker has more/different features.

Sul.