AppGuard 3.x 32/64 Bit

Make sure you use the .msi installer of Chrome and install into Program Files instead of AppData. AppGuard by default run Chrome as 'Guarded' so no worries there! You'll be able to run Chrome in 'locked down-mode' if you install into Program Files rather than AppData. Updater will update Chrome if you set AppGuard to 'install'-mode... so only do that when there's a new version available and be sure to set it back to your prefered protection mode. You have total control of what gets installed and what does not!

 

I've always had my Sandboxie container in user space (now ram disc) but thought you had to add C:\Sandbox as user space to get AppGuard compatibility. Does this mean that adding to user space manually in AppGuard just gives write permissions rather than placing genuine user space restrictions on the directory/file you choose?

Thanks

 

This whole thing with ag and sb is confusing as heck, so if I make c:\sandbox A user space folder, sb and ag won't have any conflicts?

 

Thanks Peter

So i'm assuming I put no in the column?

 

Ahhh I see, thanks

 

Thanks Pete, yeah I'd got the principles but had misunderstood the original post I think.

I thought you were suggesting that even when adding C:\Sandbox manually to user space in AppGuard it was still treating it as system space. Thankfully not.

Given my Sandboxie container is in a ram disc and therefore in user space by default it's not something I'd given a lot of thought to but I seem to recall that others suggested that to get the 2 apps to work together, if you use the SBIE default container location, you had to add C:\Sandbox to user space.

If it is no longer the case that this must be done for the apps to work together this discussion should demonstrate that it essential to do so to maintain the full protection AppGuard provides.

If it is still the case that C:\Sandbox has to be added to user space to get the 2 to work together it still leaves the question as about how execution from inside the sandbox was possible.

Regards

 

Thanks so much, Pete, exactly what I was hoping for.

Tom

 

It wouldn't. If the container is already in or is moved to user space AppGuard should prevent execution. I'm pretty clear that is a good and straightforward solution.

Seems like a bit of confusion, no doubt from my inability to articulate what I was after. I wasn't asking about your set-up particularly which looks sound. I was asking if in a default config, where you don't physically move the container to user space using SBIE functionality, a user had to add C:\Sandbox to user space in AppGuard to gain compatibility.

I asked this because I believed you suggested in post 2564 that the execution of malware from C:\Sandbox was because AppGuard considered the sandboxie container at the default location to be system space. I am not really clear on that as I had thought AppGuard prevented guarded apps from writing to system space. If it does how did the sandboxed & guarded browser write to the container in the first place let alone execute?

Cheers

 

Did you read post #2571 above where I explained what is involved in moving a folder from system-space to user-space?

 

I have everything set thanks

 

Thanks for your patience. Yes it does. I get that anything can execute from C:\Sandbox when it is not added to user space in AppGuard.

What I'm not getting is how anything would get in there in the first place if it wasn't already set as user space. A guarded app can't write to system space so if AppGuard thought C:\Sandbox was system space why did it let the browser write to it in the first place? In my quick tests tonight (Win 7 32 & 64 bit + Win 8 64 bit) I can't get any guarded and sandboxed apps to write to C:\Sandbox unless I add it as user space first.

I'll work it out though as it will likely be something else I've 'tweaked' to save you further frustration explaining it again .

Cheers

 

Bought a license. Working well just as before

EDIT: Just tried to install Malwarebytes Anti-Exploit. It was saved to my desktop, but it executed just fine on High... I got through a few screens but then it failed to install. Was it able to execute from User Space because the executable was signed? Would I still be safe on High since signed malware would still be run as Guarded?

EDIT: For some reason, after a game I have finished installing, it needs to install a couple additional things when run the first time. This shouldn't have been a problem, since I still had AppGuard set to Install, yet I got the flashing icon and these logs:

06/23/13 21:18:09 Prevented <Windows® installer> from accessing <c:\users\brandon\appdata\local\temp\ixp000.tmp\vcredist.msi <Microsoft Visual C++ 2005 Redistributable>>.
06/23/13 21:18:07 Prevented <pid: 3664> from writing to <\registry\machine\software\classes\clsid\{0aa000aa-f404-11d9-bd7a-0010dc4f8f81}>.
06/23/13 21:18:07 Prevented <pid: 3664> from writing to <\registry\machine\software\classes\clsid\{0aa000aa-f404-11d9-bd7a-0010dc4f8f81}\inprocserver32>.
06/23/13 21:18:06 Prevented <Microsoft(C) Register Server> from writing to <\registry\machine\software\classes\clsid\{0aa000aa-f404-11d9-bd7a-0010dc4f8f81}\inprocserver32>.

The bold one happened over 20 times. I just want to know why this happened in Install mode.

 

Hi Chris,

I may have misunderstood your post but it looks to me as though the nub of it is what constitutes system-space and user-space, and the protections applied to each of them.

AppGuard, as initially set up, maintains a strict separation between the two concepts, permission-wise. User-space is defined as folders that have write access for guarded applications, but they also have launch protection in order to guard against drive-by downloads.

If the configuration is changed to add write access to a system-space folder without also adding launch protection at the same time, a situation is created where the folder is in user-space without launch protection, which can lead to the appearance that AppGuard is not working correctly when the reality is that AppGuard's basic security model has been compromised by the action of the user in not following the two-step procedure to move the folder (see post #2571 above).

My understanding of the case being discussed above is that the c:\sandbox folder had initially been given write-access to move it to user-space without adding launch protection for guarded applications, which allowed a software installer to be run manually from there while in Locked Down mode.

Regards
pegr

 

Just to extend this a bit further, system-space folders have write-access protection for guarded applications, but they do not have launch protection. Moving a user-space folder to system-space also involves a two-step procedure: -

1. The folder is added in the User-Space tab, setting the Include flag to No in order to unguard its executables.
2. The folder is added in the Guarded Apps tab with the Type flag set to Read Only to prevent guarded executables from having write access.

Performing only the first step would also result in the same folder permissions situation as above. The folder would remain in user-space without launch protection.

 

Thanks Pegr, that yes/no part was the bit I was missing. Makes sense to me now.

Cheers

 

You're welcome.

 

I'm currently using AppGuard, NVT ERP (Lockdown Mode) and Sandboxie. Is EMET worth considering, or would that be overkill and redundant?

 

Redundant. AppGuard offers the same protection.