AppGuard 4.x 32/64 Bit - Releases

We may have discussed. Barb_C told me delete. Thank you. Yes, as you say. Important to learn how AppGuard works. For this scenario. I understood protecting exe launch from sandbox. That's why I've added C:\Sandbox back to User Space. I wanted to see if SBIE v5 re-write changed Events that prompted Barb_C in email and in this board to advise delete C:\Sandbox.
Caveat: There is 50% chance I misunderstood.
At the time with SBIEv4 based upon several emails with BRN and Wilders message.
At the time AG was throwing Events related to Sandboxie and those Events were reported.
At the time the consensus as far as I could determine without your current clarity was to delete C:\Sandbox from User Space.
Caveat: There is 50% chance I misunderstood.
I did head scratch then and head scratch remained.
So, I've added C:\Sandbox v5 back to User Space.
No Events ...as yet. I do have four Ignores from before adding C:\Sandbox back to User Space.
Note: User Guide v4 specifically referenced User Space + Sandboxie, by my read User Guide 4.1 and 4.2 does not specifically reference User Space + Sandboxie. Granted 4.2 does not reference Sandboxie.
Note: your current clarity two sides of the coin is not presented in User Guide 4.0
Barb_C explain as I recall, adding Exception to User Space as recommend. As normal. As best practice.
Until of course I was told to Delete.
Now, we can debate what is meant by recommend / normal / best practice.
Or, as you suggest. I should learn how AppGuard works at a level on par with AppGuard engineers and in-the-know Wilders members.
Then maybe if I'm fuzzy. Ask. But, once I learn on a level....then there won't be fuzzy's.
Seems, those in-the-know are convinced lack of effort on my part is causal to my fuz.
And fuzzy me thinks official documentation is fuzzy.
By my read now of your clarity. There's no downside to C:\Sandbox add to User Space as Yes easy to No.
That's as I imagined until I was told to Delete. At the time Events offered to BRN prompted BRN to recommend Delete.
Well, it's still best I learn on par with AppGuard engineers and in-the-know Wilders members.
As you advise....it is very difficult to give blanket recommendations to cover all cases.
I'll have to look for "AS IS" with v4.2 User Guide.
We may have discussed. And I may of had AppGuard on the shelf since.
Curious, we don't know, what we don't know, until we ask.
As always,
Regards and Much Thanks!

 

Firefox updates on my machine now while in Locked Down Mode also. AG blocks a bunch of stuff during the update though so i'm concerned that I could end up with a corrupt installation of Firefox. I'm not guarding updater.exe.

 

Since I use FF Developer Edition, I brought this to BRN's attention months ago.

No reply...

Yes. FF will now update in Lock-Down Mode.

Blocks writes to updater log - to items to be deleted - if I recall.

Since I got no reply from BRN I stopped using AG and FF together.

 

That appears to be bug.

On W8.1, after adding powershell SysWOW64 and System32 paths to User Space, they are blocked from execution.

Not added to User Space, only the powershell profile is blocked from loading since I think it is stored in .tmp or app data folder.

 

My usual routine with FF is to replace most, if not all http(s) entries in about:config with https://localhost/. Since I know what plugins/addons/extensions I require for my browser, I need not rely on FF to tell me what to update/install and when. So now when I fire off an update check of FF, it gets a reply from localhost with a response "your browser is up-to-date"; nothing from external sources. Using FF is no real issue, just nerf the phone-home elements, and voila...

I understand it is still a concern that AppGuard is letting an update check through, but it isn't a deal-breaker.

Wasn't the 32/64 file version issue brought up earlier? I am not sure what the response from AppGuards site was... would you happen to remember if one was provided?

 

• To add vulnerable process to Guarded App list just add System32 path.

• To add vulnerable process to User Space must add both System32 and SysWOW64 paths.

 

I think maybe you are referring to an issue I reported about a year ago. I reported that the user is unable to add executables from SysWOW64 folder to the Guarded Apps List. If the user attempts to add executables from SysWOW64 Folder to the Guarded Apps List they will all be removed from the list as soon as the user reboots their computer. BRN replied to me stating that if the user adds the same executable (executable with same name) from the System32 Folder then AG will also Guard the same executable in the SysWOW64 Folder without it being on the Guarded Apps List.

This is a different situation since i'm moving executables from the System Space to the user-space so AG will block them from executing. AG is blocking them, but the tray icon fails to blink for the blocked launch. AG also fails to log the blocked event. The other strange bug is difficult to describe without seeing it. I will have to just give you the same example I did earlier. If powershell.exe in the System32 Folder is made part of the user-space, and I launch powershell.exe from the SysWOW64 folder instead AG notifies the user it was blocked from launching when it actually was not. The tray icon will blink, and AG will log it as though it blocked Powershell from launching from SysWOW64 folder. AG should not do anything unless I add it to the user-space also. After I do add powershell.exe from SysWOW64 folder to the user-space AG blocks it like it should, but does not notify the user it blocked it from launching in any way. The bug is only with notification, and logging. AG moves the System File to the user-space successfully. AG just fails to notify the user when it's blocked from launching, and fails to record it.

 

Yes, I think many users do not realize the difference in how you have to do it.

 

Sent: Sunday, December 27, 2015 10:24 AM
To: appguard@blueridgenetworks.com
Subject: AG CONTACT
Message:
I have c:\users\user in User Space and was wondering about adding to Guarded Folders.
c:\users\user\documents -- Private
c:\users\user\pictures -- Private
c:\users\user\downloads -- Private
c:\users\user\desktop -- Private
Comment

--------------------------------------

appguard@blueridgenetworks.com 12/28/2015
To:xxxxx@xxxxx.com
Hi BJ,
We do think that it is a good idea to add those folders as Private folders.
Regards,
Barbara Cline
AppGuard Support

 

good question lol

i guess his browsers have privacy turned off. personally i wouldn't do that.

 

The way Private Folders works has the following implications:

• Folders should not be made private if they need to be accessed by a guarded app that has the privacy flag set to On. The browser download folder is a case in point. If the download folder is made private then the browser won't be able to access it unless privacy is turned off. But setting the privacy flag to Off turns off Private Folders for the browser, which would then have access to all private folders. The obvious conclusion is that the browser download folder should not be made a private folder.

• Apps that should be guarded include those that access the Internet and those that open data files that may contain embedded code. In the latter group are things like office applications, media players, picture editors, PDF readers, etc. As a lot of personal data is created by, and accessed by, applications that should be guarded, it follows that guarded apps that access private data should have the privacy flag set to Off.

This leads us to the following conclusions:

• The main use of Private Folders is to prevent web browsers from accessing personal data. Folders containing personal data should be made private and web browsers should be guarded with the privacy flag set to On.

• Folders that do not contain data that needs to be protected should not be made private.

• Guarded apps that do need access to private data should have the privacy flag set to Off.

Note that in none of this has the user profile been mentioned. The location of a folder is irrelevant in determining whether or not it should be made private.

 

Is this generally recommended, i.e. not covered within AG default settings, a vulnerability?
And if so, should one use the first option (Guarded App list), or second (User Space) - or both?

 

I recommend adding all web applications to the Guarded Apps List as long as it does not break the application's functionality. I personally have never ran into this problem.
If it is a system resource that you never use, or do not need then I recommend adding it to the user-space if you are sure it is not required by the OS. This will take some knowledge on the user's part. Powershell is not required by the OS, and very very few home users need it. It is often used by malware to infiltrate the system so I see no reason to even allow it to run. In my opinion this is the perfect example of when to add something to the user-space instead of guarding it.

You asked if the application should be Guarded, and added to the user-space. I think doing both may just cause problems because how is AG going to know which policy to enforce on the executable. Maybe there is a reason to do it, but i'm not aware of any reason myself. I'm not sure how it could be used like that because if it's added to the user-space it will not be allowed to launch so there's no reason to guard it. That's the whole point of adding it to the user-space.

edited 12/29 @ 8:56

 

Thanks C_E. Have added System32 and SysWOW64 powershell.exe and powershell_ise.exe to User Space. Even if there is a bug #3976.

 

No problem!

 

It should not be a security problem. AFAIK, the bug only causes AG to fail to notify the user of the blocked event by failing to blink the tray icon, and logging the blocked event.

 

I don't think it is a bug in AppGuard. My theory is that Firefox calls updater.exe (in it's own directory) and updater.exe then starts a service which performs the update. Starting a service is different than launching an application so the AppGuard inheritance is not in play. Perhaps it should be? Or perhaps a Guarded application should not be permitted to start a service. Things to consider.

BTW, the service is "C:\Program Files (x86)\Mozilla Maintenance Service\maintenanceservice.exe". I haven't tested it, but I believe that if you Guard it, then AppGuard would block the update.

 

While I'm on here, I should mention that the beta version of 4.3 will most likely be available later next week. Too many people on vacation this week to get it out sooner. Sorry for setting unrealistic expectations.

 

Why not change the extension for those two files to .bak or something similar...

 

Could you please increase the number of power applications from 16 to at least 20 or so?
thank you!