AppGuard 3.x 32/64 Bit

Also, does this version add any new protection features, or is it focused on making AG more user-friendly?

 

Did you have AV software running when you saw this error? Have you been able to install?

 

Yes, if something runs from user-space AppGuard 4.0 doesn't seem to recognize it as a PowerApp. Same goes for Process Explorer. With 3.x I used to run it from user-space and as a PowerApp and it ran fine. With 4.0 I am getting a lot of memory-guard protection blocking events in the activity report. That's because procexp.exe creates a procexp64.exe in C:\Users\Admin\AppData\Local\Temp. Adding that file at that location seperately as a PowerApp does not work as well. If I put it in C:\Program Files\ProcExp\ it will work just fine without being a PowerApp.

 

No, in version 4 they still run fine if in Power Apps. Both the problem programs are in Program Data instead of Program Files, so I guess that's why there were problems? With

c:\programdata\battle.net\agent\agent.exe
c:\programdata\battle.net\client\blizzard launcher.exe

added to Power Apps, the game runs fine.

 

Hi Barb,

Here are some preliminary comments from initial testing on 32-bit Windows XP: -

1. Installation over the top of 3.5.6 was clean and MBRGuard successfully removed.

2. Existing ignore message rules were deleted during the upgrade (this is an existing bug in 3.5 that still persists in 4.0).

3. The tray icon never changes. It's permanently blue with a green tick, no matter what protection level is engaged, and does not blink on a blocked program launch. This is a bug that needs fixing.

EDIT: After a further restart, the tray icon display is now working. Looks like it was just a minor installation glitch. The tray icon could do with being a bit bigger though. It is smaller than all of my other tray icons and it's hard to see the overlays due to its small size. It's nice to see the overlay change to a padlock on Locked Down in order to distinguish it from Medium.

4. The option to keep protection lowered during a restart has been removed. This option should be reinstated in order to avoid any possibility of interference with software installs that require a reboot to complete.

EDIT: Oops! I didn't spot the checkbox that controls this when moving the slider to Install. There is a small bug in the text next to the checkbox though. When the checkbox is checked, protection correctly returns to the previous level (Medium or Locked Down) after the timeout period, but the text doesn't reflect this. It always says returning to Medium even when returning to Locked Down.

5. The new MemoryGuard policy looks good. I have seen MemoryGuard events in relation to guarded apps but none have caused any issues. Nonetheless, there needs to be the option to create MemoryGuard exceptions, just in case a guarded app does fail to work corrrectly due to blocking by MemoryGuard.

6. I never needed to use the Power Apps feature with version 3.5 and that hasn't changed with version 4.0.

7. Apart from ensuring that the Sandboxie container folder is in user space (it's still necessary to move it if in it's the default location of C:\Sandbox), the only exceptions I previously had to make were MemoryGuard exceptions. These are now no longer needed due to the new improved MemoryGuard policy.

8. I haven't tried updating guarded applications in the Medium protection level yet, so can't comment. I will report back when I've tried it.

9. The new simplified GUI is to be commended. However, the way system space and user space are represented and handled within AppGuard needs to be simplified. It still requires a two-step procedure to move folders in both directions between the two spaces, which is clumsy and potentially confusing to new users. As soon as I get time, I will send you a PM with an idea about how this could potentially be improved in a future 4.x release.

10. The embedded help file is for the previous version, but I assume this will be updated as part of the final RTM.

Kind regards
pegr

 

Is Adobe Reader set as a trusted publisher Pete? I think that is set by default by AppGuard. I'm sure that Barb will weigh-in on this, but that may account for the different results.

Dave

 

Hi Pete,

As far as I can see, the main use of the Publishers list has always been to enable installers to run from user space, where the application executables are installed into system space, without the user having to explicitly lower the protection level to Install.

The installed application running from system space may still need to be explicitly guarded via the Guarded Apps list. There's nothing contradictory about this as the protection level always has to be temporarily lowered while installing or updating software, and what the Publishers list is doing is to automate this for trusted publishers without requiring manual user intervention. This is convenient and allows for unattended software installs/updates when not running at the Locked Down protection level.

IMO the implementation of the Publishers list is poorly thought out though for the following reasons: -

• The Install column flag is redundant. Unless it is set to Allow, I can't see any point in adding a publisher to the list in the first place. All of the entries automatically created by AppGuard have the Install flag set to Allow.
  
  
• The Guarded column flag is redundant. Setting the Guarded column flag to Yes and the Install flag to Allow would be contradictory. This configuration would allow user space launches to write to system space in order to install software, whilst simultaneously guarding them so they can't. In version 3.5, most of the entries automatically created by AppGuard had the Guarded flag set to Yes. This has now changed in version 4.0 and all of the entries now have the Guarded flag set to No. I suspect the reason for the change is to address the issue of automatic software updates at the Medium protection level in 4.0.
  
  
• The MemoryGuard flag is redundant as MemoryGuard now only applies to Guarded Apps and all entries in the Publishers list have the Guarded flag set to No.
  
  
• The Privacy flag is redundant. It isn't relevant to software installation by trusted publishers, and is better applied via the Guarded Apps tab to the installed application running from system space where the user decides that the application is a privacy risk.

The conclusion is that all of these flags are redundant, as they should all be set as follows: Guarded = No; Privacy = Off; Memory = Off; Install = Allow. All of these flags should be removed in order to further simplify the GUI. All that is needed is a simple list of publishers that are automatically allowed to do system space software installs from user space at the Medium protection level. No additional configuration flags are required. I can't think of any situation where it would make sense to set the Install flag to Deny or the Guarded flag to Yes, as this is the default behaviour for user space executables anyway. For the Publishers list to serve any useful purpose, the Guarded flag always needs to be set to No and the Install flag to Allow.

This leaves one outstanding point to be addressed: applications that install into and run from user space. IMO the best way to address this is not via flag settings in the Publishers list but following the two-step procedure described elsewhere to move the program folder from user space to system space. If a folder holds system objects such as programs, and not user data, the folder belongs in system space, with any application configuration handled via the Guarded Apps tab.

If these flags were removed, not only would the GUI be further simplified, but it would be a lot clearer as to what purpose the Publishers list serves. I can't think of any situation that might involve changing these flag settings that isn't better handled in other ways. All of this is just my personal point of view. Barb may see it differently, but I hope she reads this and comments.

Kind regards
pegr

 

If that's true then there's a bug in AppGuard. Any executable can write to user space, irrespective of whether it's guarded or not. What guarding does is to prevent writing to system space. If what you were saying is that the launch from user space is blocked, that's what the Publishers list is supposed to handle.

 

I know you are busy with Beta Testing 4.0, but I need some help with 3.5 please guyz

I get this

10/11/13 12:16:25 Prevented process <Firefox> from writing to <c:\users\Admin\appdata\roaming\mozilla\firefox\profiles\i4wdl0fq.default\telemetry.failedprofilelocks.txt>.
10/11/13 12:16:25 Prevented process <Firefox> from writing to <c:\users\Admin\appdata\roaming\mozilla\firefox\profiles\i4wdl0fq.default\parent.lock>.
10/11/13 12:16:25 Prevented process <Firefox> from writing to <c:\users\Admin\appdata\roaming\mozilla\firefox\crash reports\installtime20130910160258>.


This is when I try to run Firefox as an Admin User.

I tried this,

10/11/13 12:16:20 User added <c:\users\Admin> to user-space folder list, launching is <enabled>.

But it didn't help

Thanks !

 

Have you noticed any problems with firefox? Do not turn off this location from the user-space protection.

 

Thx,

No I haven't noticed any problems with Firefox at all.

I only can't run Firefox Elevated from my (Non-Admin) User account, only when I switch Appguard to Install mode then it works.

Ps: I am getting this error msg.



(And no, FF isn't running )

 

I'm not sure if the inheritance mechansm applies to the Publishers list. What I'm now wondering is whether one of the exe files that tried to run from user space wasn't digitally signed.

 

I believe it is because Adobe is included as a trusted publisher.

 

Thanks for the reminder about this. Will do!

 

The inheritance mechanism does not currently apply for trusted publisher. That is one of the enhancements we're looking into for 4.1.

Some of the installers are not completely digitally signed (i.e. they have executables within them that they launch that aren't digitally signed - that is why some trusted publisher's installers sometimes fail).

 

In this case, it is not user-space protection that is blocking Firefox, and if you're logged in as "Admin", then AppGuard should not be blocking Firefox from writing there. Are you logged in as another user and then elevating to Admin?

I would consider adding "c:\users\Admin\appdata\roaming\mozilla\firefox\profiles" as an exception folder on the Guarded Apps tab. I would also strongly recommend removing the user-space exception folder - since you will be allowing Guarded apps to write to that folder, you should not allow apps to launch from there. I don't think that you need to add the "crash reports" directory to the exception folder list (but it probably wouldn't hurt). I believe if you make the changes that I've suggested that Firefox won't crash.

 

Some good suggestions! We will really be focusing on the installation issues in the next version (4.1) and I think that you've offered some really good insights!