AppGuard 4.x 32/64 Bit - Releases

Thanks so much, Pegr. Not sure I understand the logic behind all of the various AG settings, but your suggestion worked.

 

You're welcome. The reason your program was blocked was because it was trying to run from a folder within your user profile, which AppGuard considers User Space. Adding the folder to the User Space tab and setting the Include flag to No tells AppGuard to ignore program launches from the folder, which allows the program to run.

 

I have made the following observation:

when guarded apps are running and I switch to install mode, they stay guarded. I guess this is expected behavior. However this does not apply to Internet Explorer or Google Chrome. When they are running and I switch to install mode, both guarded execution and privacy mode are disabled for them. Is this supposed to be like that?

Windows 8.1. Pro x64

 

I haven't tested this as I use firefox but I believe this may be because IE and Chrome still spawn child processes. If this is the case then after appguard is disabled/switched to install mode these new child processes won't be protected like they would normally (enabled protection) however any process running beforehand (including existing IE and chrome) should still follow the rules applied to them at launch.

This is only my understanding of how it should work. I may be way out of the ball park and hopefully someone will let me know if so but those are my initial thoughts as to why you have seen this behavior and I do believe it would be normal.

 

Today I installed v. 4 on my second pc, but after the reboot AppGuard doesn't work: the service run in MS Services, but it's locked. The configuration on my second pc it's the same than the other, only I run XP instead Seven, so I can't understand.

 

I also think it is due to child processes. Any executable set to Guarded will remain so, but if it's a child process that is not explicitly Guarded, then it will lose protection when AG is set to install. When AG's protection is resumed, child processes will still be unprotected.

 

I don't understand your explanation. Chrome and Internet Explorer become unguarded when install mode is activated and so would any child processes that are spawned in the duration. How is this intended when all other guarded apps stay guarded during install mode?

 

Perhaps their main processes are child processes. Take the new Opera for example, the start menu shortcut executes Program Files\Opera\launcher.exe, and launcher.exe will then launch Program Files\Opera\20.0.1387.91\Opera.exe and terminate itself.
I'm also not sure if the child processes becoming unguarded during install mode is intended or a bug.
Hopefully Barb will soon chime in here.

 

There aren't that many programs that constantly launch child processes. IE and Chrome are pretty much the only ones I've seen launching so many. Most programs, if they launch a child, do so at the initial startup usually as a launcher or part of a protection scheme and then that's it- they continue to run and are not constantly launching new children. As such switching to install mode would have no change to them, unless they were restarted.

IE and Chrome differ in this regard as they constantly launch new children when opening new tabs etc. It would take some testing to see if the 'appearance' of being unprotected is in fact due to these newly launched children after install mode is set. If I were to test it, I'd be checking the PID's mainly to see if new ones are being spawned.

I'd expect it to look something like this.

iexplorer.exe PID 1116 (parent/remains guarded)
iexplorer.exe PID 1152 (child/remains guarded)
visit a web page
iexplorer.exe PID 1176 (child/remains guarded)
switch to install mode
open a new tab/page/launch exe etc from inside
iexplorer.exe (or launched installer) PID 2132 (child/unguarded due to following rules set in appguard at the time of launch)

I'd expect that the original parent/child do stay guarded. However any new children, after install mode is set, would instead follow the install mode rules, as they are being 'launched' just as if you were starting up an entirely new program even though the end user still sees same interface the entire time from one of the two originally launched exe's, while these children processes are being spawned in the background tasked with the work for each page.

As I said before this is just speculation, hopefully barb can say for sure. If we don't hear anything soon I'll fire up a VM and do some testing myself to see.

 

When I try to download and save a file on my computer the original chrome.exe with medium integrity, which fathers and supervises all chrome.exe child processes, has to be responsible, because the child processes don't have file system access as this is the policy of the sandbox. So my theorie is that the original chrome.exe becomes unguarded and loses privacy mode, because I can save files in system space and private folders while in install mode.

 

What could have triggered this? (AG was locked down I think.)

I added a folder on my desktop as private in Guarded Apps folder settings. Also for the first time I added c:/sandbox in AG User Space tab with yes include option to have AG protection for start/run inside SBIE sandboxes.

I did a reboot. I started Chrome in a sandbox and this popped up:

AppGuard has blocked <Sandboxie COM Services (CryptSvc)> from accessing the Private Folder: c:\users\myuseraccount\desktop\that_private_folder\pokerista

I can't see what starting Chrome in an empty sandbox (I think it was empty since I make it to autodelete) has to do with that message? One thing could be that it had nothing to do and was only coincident popping up exactly same time. It is only that I as far as I remember all my sandboxes were empty and had nothing to do with that desktop private folder.

What was done before:
I did make a test and fiddling with installing a chess program to a chess sandbox, making sandbox/chess folder with no include option if i remember right. Anyways I got the program installed, the install file was from the downloads folder. Better I think is to use Allow User Space launches for install with the tray icon. Somehow I could not delete the contents of chess sandbox, some error. So I rebooted and deleted chess sandbox contents from the SBIE tray icon. Removed also that subfolder exclusion from AG User Space tab. All fine.

Starting Chrome sandboxed caused the above bold message. The only thing that I had connected to that private folder was: I installed the chess program to sandbox and also did cut the SBIE install file from that same downloads folder to that private folder. Done with unsandboxed explorer. But not to that poker subfolder. Really strange. SBIE corrupted?

 

Is Pokerista the private folder you added? If so then that would be the reason your Sandboxie COM Service is being blocked from accessing Pokerista. If you define a folder as private then other applications are not allowed to read, or write to that folder.

 

That's not correct. You can include or exclude folders in the user space tab. That depends on what you are trying to achieve. I have made use of both possibilities in the past.

C:\Sandbox is system space by default. Thus everything in there can launch, has privacy mode disabled and is not memory guarded, unless it is explicitly listed in the guarded apps tab. If you want these protections inside the sandbox folder, you should include in user space. I have my Sandbox folder included in user space as well.

 

I think I was wrong with that. It's rather explorer.exe as a child process of chrome.exe.

 

Yes it is a subfolder and as such also private. I can vaquely perhaps understand it being blocked. My question is why is that service trying to access it at all. That folder is not related as far as I know to any Chrome browser activities. At least so I hope.

 

I do not use Sanboxie so i'm note sure why. It appears to me that Chrome is communicating with that folder. Do you save files to that folder from Chrome?

 

When you click on 'ignore message' there may be additional information. For example another application might try to access that folder through Sandboxie Com Service.

Like this:
c:\program files (x86)\google\chrome\application\chrome.exe | c:\windows\explorer.exe

The activity report itself would only show chrome.exe here.

 

Adding a folder as a private folder that is shown when opening the explorer while trying to save files is enough to trigger that message. You don't have to try to actually save something there.

 

Btw.. as FleischmannTV stated above C:\sandbox would be part of the system space so I do not see any reason to add that folder to userspace. What is your reason for adding it to the userpace?

 

I have already answered that and further it has nothing to do with the private folder issue.

 

Chrome is such a nightmare for security vendors. This forum is full of conflicts between Chrome, and security products. I'm so glad I don't use Chrome!

 

FleischmannTV, do you use Sandboxie?

 

It has nothing to do with Chrome. You will get the same message with most browsers, when you try to save a file and a private folder is shown in the explorer window. You don't have to try to access the private folder on your own. If it was opened before, explorer remembers this and the next time you try to save something anywhere, explorer remembers the last view.

I have been using AppGuard together with Sandboxie for months.

 

Thanks FTV, but not really, there are:
C:\Program Files\Sandboxie\SandboxieCrypto.exe | C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
c:\users\user\desktop\ajankohtaisia tiedostoja\pokerista

At this moment I am again not getting overly paranoid sigh. There was some mess when I could not delete that chess game sandbox contents from SBIE tray icon and had to reboot before I could. Perhaps some memory thing with either AG or SBIE caused this.

The other possible paranoid ideas coming to mind is that Chrome is spying on my private stuff hehe.

I might have done something like that. I propably hade that folder open in explorer, not sure if i saved anything with a browser though.

 

Jarmo P. Exactly as I have suspected. Chrome is trying to access that folder, not Sandboxie, believe me. The example I have listed is just an example for one process trying to do something through another process. And as I have stated before, it doesn't have to mean that Chrome is sniffing there. It could be explorer related.

I get these reports all the time.