AppGuard 4.x 32/64 Bit - Releases

It is a bug. I have seen this block many times during testing. It happens randomly.

With other programs that have Privacy Mode enabled - like Chrome - we expect to see such blocks. Chrome sweeps the file system and will attempt to read directories, including sub-folders, when you use its file explorer. For example, when you attempt to save a file a downloaded file to My Documents from within Chrome, Chrome will attempt to read My Private Folder, and that read of My Private Folder triggers AppGuard to block the read and generate a Privacy Mode alert.

AppGuardGUI.exe is not a Guarded App. So the short of it is that it is a bug. The bug has been on the Bugzilla list for a low-priority fix.

I understand that some people will find such bugs annoying, but they are harmless.

 

thank you

I did install chrome the other day but have not tried to download anything with it yet.

"You can prevent such alerts by disabling (un-ticking) pop-ups and toasters on User Space tab > Privacy Mode."

I have those unticked now.

 

The built-in Windows alert is sufficient - and it will eliminate the superfluous AppGuard Privacy Mode alerts. Those alerts, strictly speaking, are not bugs nor false positives (only the AppGuardGUI.exe is a bug\false positive). AppGuard is correctly alerting the user when a program with Privacy Mode enabled attempts to even read a Private Folder - which isn't direct access.

Using the built-in Windows alert will generate an alert only upon an attempt at direct access. It will show "Access is Denied"\"You don't have permissions..." or some variation thereof.

 

@Jeff_T Testing Group Probably covered already in this thread, but at some point in my AppGuard hardening, I unticked Microsoft (C) Register Server (c:\windows\system32\regsvr32.exe only) in Guarded Apps tab, and included (c:\windows\*\regsvr32.exe) as User Space=Yes.

I have seen this block sometimes though, I think during/after Dropbox (again) self-update - with no apparent ill-effect that I could see though:

01/12/17 01:25:34 Prevented process <regsvr32.exe | c:\program files\dropbox\client_17.4.33\dropbox.exe> from launching from <c:\windows\syswow64>.
01/12/17 01:25:33 Prevented process <regsvr32.exe | c:\program files\dropbox\client_17.4.33\dropbox.exe> from launching from <c:\windows\syswow64>.

Best to leave regsvr32.exe as is, or revert to 'Guarded'?

As I have posted before, I have the same situation with powershell, which I think is invoked by some Lenovo utility, but not sure - can't see in Activity Report. IIRC, it occurs daily at noon, but I haven't spotted a task in the scheduler, though I haven't looked to hard.

So toying with putting these back to 'Guarded' (though I suspect you would 'guard' against this) ... but would that stop the blocks?

 

If regsvr32.exe is guarded and Firefox is updated in Protected Mode, the following is not blocked (as expected):

But if regsvr32.exe is added to User Space with Include=Yes this will be blocked and you'll see more blocks, especially for installations/self-updates,etc.

It can be added to User Space but for installations it's better to set it to User Space=No

 

you know that there is an option called "Allow Install " right?

 

As @mood points out, regsvr32.exe is active during some software installations\updates. Sometimes all it does it register the App ID on the system.

For convenience, just make it a Guarded App.

An important point regarding the hardened xml is that it is not static. It is meant to be adjusted\customized by the user as necessary.

The hardened xml has a lot of processes and directories added to User Space (YES). So blocks are to be expected at some point.

If the user wants to micro-manage processes, then it is possible to do so by always keeping the process disabled and allowing it only when needed. If the user wants to allow programs for convenience, then it is possible to do so by allowing it permanently.

It is up to the user to decide to allow temporarily or allow permanently - for they should know generally what processes launch on their specific system and the frequency at which those processes launch. The typical AppGuard user here at Wilders tends to be more observant, more aware, has a higher willingness to stop and investigate, and more security conscious.

With or without the hardened xml, as long as AppGuard's protection is enabled and maintained, the system has very high protection. The hardened xml was designed to block an exploit run sequence at a point earlier in the run sequence instead of just the final payload. That is it. That is the sole, intended primary benefit of the hardened xml. There are other benefits to using it, such as protections against malicious *.lnk files. I added that later.

Also, it adds protections if a user decides to employ - "Allow User Space Launches - Guarded" - which I would expect none of the people here at Wilders would ever use that option except with a known\trusted\safe program. If it were up to me, then I would remove the "Allow User Space Launches - Guarded" option in the tray icon - because those that don't understand what it does can create a user session infection that results in data theft or file encryption.

Some users never see regsvr32.exe launch. What launches on one system versus another is highly dependent upon what is installed.

 

How can I keep AppGuard from interfering with Sandboxie using delete command?

I get this from AppGuard:

Code:

01/13/17 16:14:46 Prevented process <Windows Command Processor> from writing to <c:\sandbox\user\__delete_chrome_01d26dfb36968a49\01d26dfb-369b4d09-00000001\1060b7adde0ff6de85637bf89fc4cebc_bb53b5deed3efcc221707cc8478e30bf>.

And I get this alert from Sandboxie, the capture.

 

Make C:\Sandbox an Exception Folder (Read\Write access) on Guarded Apps tab > Settings

 

@Jeff_T Testing Group While your suggestion should do the trick I would like to recommend that they add C:\Sandbox to USER SPACE instead.
By default new folders on C:\ are treated as system space where generally AppGuard doesn't apply launch protections to anything created there unless specifically told to. So simply converting the sandbox folder to user space should take care of the delete issue since guarded apps can then modify it. In addition this will also apply AG protections/rules (eg digital signature requirement if at default level) to anything created in any of the sub-folders or sandboxes stored within that location.

 

If you add C:\Sandbox to User Space (YES), then you have to create launch exceptions for what you wish to allow to execute in the sandbox - for example a browser.

I know how AppGuard works.

 

Settings adjustments in AppGuard for Sandboxie:

1. AppGuard tray icon > right-click > AppGuard... > Customize > Guarded Apps tab > Settings > Add > C:\Sandox > OK > Exception Read\Write (drop-down menu)

2 is optional\is not required. You can already control what will be allowed to execute inside the sandbox right from within Sandboxie itself. So adding the sandbox to User Space is not required unless you want to control what is launched in the sandbox with both Sandboxie and AppGuard.

2. You can add C:\Sandbox to User Space - and then create exceptions for (exclude the process from User Space) any programs that you have allowed to run in Sandboxie

For example, when I used Sandboxie I only allowed Cyberfox and any additional required processes to run sandboxed. I added C:\Sandbox to User Space (YES), but excluded the Cyberfox's sandbox file path from User Space (NO) - so that Cyberfox could execute.

 

This worked, thanks.

 

I wasn't suggesting that you didn't, simply explaining the thought process behind what I said.
It's certainly up to the user on which approach they prefer but I do find it odd that you wouldn't want AG applying its protections there as well. I love how AG blocked read memory for sandboxed apps.Oh well, to each his own!

 

Actually, a user should ideally place the sandbox on a non-system partition, but that is up to the user to decide on their own.

I limited my answer to the OP's initial question.

 

That is the best solution, anyway who want a isolation container located on the system partition (if you have several partitions), this is illogical...

 

My point was, if the user decides to add regsvr32.exe to User Space the user will get more blocks in Protected Mode.
But the user can switch to Install Mode, that's fine too.

 

I agree completely. It's up to the user to decide for sure. If they want convenience over security then by all means allow AppGuard to treat it as system space and simply add a read/write exception and hope that at some point you don't go back in and manually start something else inside which isn't on the AG list and it could've blocked or applied its protections to then complain when AG didn't do anything.

Otherwise, if started as a child process AG will still apply its protections. So aside from a bit of potential leakage SBIE will keep the computer safe. I just think it's better to have it defined as user space so AG applies its protections at all times. Each to his own though!

If its not considered system space [eg non-system partition], guess what, it's user space which was what my suggestion involved adding the sandbox folder as. Why are we going in circles over this?

 

Because some people here are quite paranoids and stockpile conflicting softwares , which requires several settings optimizations, so we have to repeating the same stuff all the time if not they will say "that product suxx" ?

 

Well I suppose that's what confuses me most here. This is a thread about AG. My response was aimed for the most security conscious resolution and still keeping AG protections in the mix even for sandboxes with a single change, just like his was a single change...

In addition he basically said you could just rely on SBIE run restrictions which is true to a point from the anti-exe aspect but you still lose other things like the memread protection from AG. As a BlueRidgeNetworks employee I'd think he would want people to keep the AG protection active even if someone is running something sandboxed. I sure think it's the wiser choice, harder to set up perhaps...which is why I am so confused that he turned around and said it's better to keep the sandbox in user space to start with...That's all my suggestion involved - adding it as user space! Go ahead- rip me a new one, I'm done trying to defend my suggestion and the reason why I stopped posting on this forum so often has just been reinforced.

 

@Infected asked a question and I answered it. When 3rd-party software is involved, that is where my obligation ends. I have no idea what the poster wants to do. If they want to create a more secure, but complicated configuration, then all they need to do is ask.

 

I understood that

it is a particular case, directed to the member which has issue when Sbie close. This member don't have the full knowledge (yet) of how AG functions. So Jeff gave the simplest option.

then it was talking to us , who have a deeper knowledge of AG.

 

Thanks for clarifying your position on security/privacy via AppGuard, when a 3rd party app is involved: it suddenly no longer matters? At least I'm not confused by your choices any more! I mean why on earth would someone on a security/privacy related forum expect a security/privacy related solution?

 

I completely agree. The most logical decision from a security perspective would be to put the "isolation container" on a partition with the letter Z. The letter Z is the one furthest away from C: and this minimizes the risk of infection because malware cannot reach over from Z to attack C. Only people with great computer knowledge know this and I have great computer knowledge. The best!

I for myself can account for countless container escapes just because the "isolation container" was located on C:\Sandbox\. This defeats the concept of isolation entirely. In my opinion Sandboxie shouldn't even install if C:\ is the only available partition. There is no isolation! SAD!

 

This is just my opinion.

As far as i know, AppGuard never had a forum, except here. And as a product it has been offered to us as a quite consumer one, as protection.

And now here I read posts, like people should have separate partitions and such! When you buy a new laptop, things are usually like a normal person just replies the questions that popup. Things like partitions etc. are far from their minds.

Now this thread seems to be like some beta testing. This Jeff (hjlbx) asks questions that are so far from what a normal user wanting to do from AG. I saw him learn, now he knows more than me of course.

Could the more curious questions be limited to pms and this thread still serve as something to us that bought AppGuard as our personal protection. Us who are not into hacking, but just use the product for our protection?

Things like you install some settings, are not what we want, us normal users. Just use AG as a security consumer product. I sort of miss Barbara and other guys before this happened.