AppGuard 3.x 32/64 Bit

Added sandboxiercpss.exe,sandboxiedcomlaunch.exe, sandboxiecrypto.exe to Power Apps. Didn't even need to add those to memory guard exceptions as the power apps entry took care of that (nice ).

I have moved my Sandbox container to user space though (ram disc actually). If you still have that at the default location you can add C:\Sandbox to user space in AppGuard or add it as a read/write exception for in the guarded apps tab.

Cheers

 

Cool. Did you have any problems with the browser running slowly? I had appguard running in lockdown but firefox would be slow to open (added 5 seconds) and occasionally it would lag while loading pages.

 

No. Everything is flying so far but then again I use Waterfox and Iron rather than Firefox. Waterfox starts and loads 4 tabs in around 4-6 seconds sandboxed and guarded.

Cheers

 

what would be nice is when a new version is found by AG that it will download the installer or ask you if you want to. so you can update.

 

I go along with that

 

Whats this new power apps settings in the new beta?

im just running the most stable not the beta.

 

Refer to this post https://www.wilderssecurity.com/showpost.php?p=2038566&postcount=845
On Win7x64, I've reverted to the previous stable release due to persistent AppGuardAgent service crashes. (null pointer class dereference)

 

The behavior i'm seeing on my machine is that adding an application to power apps does not grant that application the right to write to the memory of guarded applications. I have Webroot secure anywhere, and Online Armor installed. AG is blocking them both from writing to the memory of Firefox which is a guarded application.

 

I have found that it is not enough to add some applications to Powerapps in the directory C:/programs/, and expect them to operate or update as expected. Some applications will envoke a process from the userspace, and AG will block the new spawned process. I found this to be the case with WSA, and Hitman Pro. My solution was to add those applications to the trusted publishers list with the following settings: Guarded: No, Privacy: No, Memory: No, Install: Yes.

 

I really don't like the decision to remove all blocked events other than Blocked Launches from the GUI events panel when the alert level is set to "Normal" in the new AppGuard 3.3.2 beta. This is compounded by the fact that if the alert level is set to "Normal", ignored message rules are honoured but if the alert level is set to "All" ("Verbose" in 3.2), ignored message rules are ignored. It now makes creation of ignored message rules for Guarded Execution, MemoryGuard, and Privacy events a very cumbersome process.

Here are the steps that are now involved to be able to use and create ignored messages for blocked events that are no longer displayed in the GUI: -

1. The alert level has to be set to "Normal" for existing ignored message rules to take effect.
2. The Windows event log has to be used to view blocked events that are no longer displayed by the GUI.
3. A blocked event logged only in the Windows event log has first to be captured by the GUI before an ignored message rule can be created.
4. In order to capture a blocked event logged only in the Windows event log, the alert level has to be changed to "All" and the blocked event recreated.
5. Once the blocked event has been captured by the GUI, an ignored message rule can be created but it won't be effective because of the alert level.
6. The alert level has to be reset to "Normal" for the newly created ignored message rule to take effect.

This entire procedure for creating ignored message rules is now unbelievably cumbersome and counter-intuitive as compared to AppGuard 3.2 where all blocked events are captured by the GUI when the alert level is set to "Normal". I strongly urge BRN to reconsider before going ahead with this.

Perhaps a better way to implement this would be to add a new "Low" alert level for non-display of blocked events, and leave the "Normal" alert level the way it is in AppGuard 3.2 for users like me who appreciate just how easy it is to create and use ignored message rules in the current release.

 

I agree with pegr and like this suggestion for alert settings.

Dave

 

I agree with Pegr also. I'm glad to see i'm not the only one that does not like the limited option of the new alert system. Here are two emails I sent BRN yesterday about this topic.

I miss the old AG alert system. I like to know immediately if AG is blocking something. It makes it much easier on the tester for trouble shooting. I also like to know when possible malware is being blocked in real time. It's getting tiresome having to check Windows event viewer all the time. Currently there's Off, Normal, and All. I would like to see an additional option between normal, and All that was like the old alert system. Maybe Off, Normal, Elevated, and All. Elevated would be the option to log directly to AG's log in realtime like the old alert system. That's my preference anyways.

Sorry for the double email, but I just though of another option that may be simpler. There could be a tick box option that gives the user the option to tick a box under alert options if the users wants the Appguard logs that are being logged in windows event viewer to also be logged directly to AG's event log. That would give the option to have the old style alerts as well.

Cutting_edgetech

 

Actually, I like this option better than what I suggested but I would go further and implement it in the same way as all the other tabs work currently, with each Yes/No column setting selectable via a drop-down control. The redesigned Alert tab would look something like this: -

Event Type.............Blink Icon.....Report Status.....Log
Guarded Execution..........No..................Yes............Yes
MemoryGuard.................No..................Yes............Yes
Blocked Launches...........Yes.................Yes............Yes
Privacy.........................No...................Yes............Yes

This would provide both a consistency of visual appearance with the other tabs within the GUI combined with maximum flexibility for the user to choose how they want their AppGuard alerts configured.

 

Pegr, that is a great ideal if they can pull it off in time for the new release! If not then they need to give some sort of additional option for the old style alert log. Options that have already been described above such as a tick box or an elevated alert level in the slide bar that will allow alerts directly within AG's alert log viewer.

 

I certainly agree they need to do something to change this before the release. I don't find it acceptable the way it is currently in the beta.

 

This is why we have a beta - to get your feedback. So thanks everyone who made a comment.

I also don't like the new alert scheme after using it for a while, but the reason we tried the new way is to reduce the number of trouble tickets that we get related to these mostly benign blocking messages. We've had several trouble tickets indicating that AppGuard is interfering with a Guarded application. They're basing that conclusion on seeing the blocking messages - not the application's behavior so we'd prefer to "hide" these messages.

Ultimately we would like to use Pegr's suggestion (actually we've been planning on implementing this feature for a while), but haven't been able to work it in to our schedule.

One compromise we've thought of (that we may be able to get into the current release) is to have a menu selection that will retrieve the most recent (last hour's worth) AppGuard events from the Windows Event Log and display them in the AppGuard GUI. That would take care of the "Ignore Message" problem.

And of course, we can always revert back to the previous Alerts policy (which would be the easiest for the developers, but does not help me - trying to explain that although AppGuard is blocking a Guarded Application's risky behavior, it is not really affecting the application's performance).

Also, what do you think of a compromise of displaying the Guarded Execution blocking messages in the AppGuard GUI, but not displaying the Memory Guard blocks (which rarely interfere with an Application's performance)?

So the options are:

1. Leave as is in the Beta (probably not an acceptable option).
2. Revert back to the old alert policy.
3. Report Guarded Execution blocks to the GUI; MemoryGuard events only report to the Windows Event Log.
4. Leave alert level as is in the Beta, but provide mechanism to retrieve and display windows event log messages.
5. PEGR's suggestion of allowing the end-user to modify the alert levels: This is obviously the clear choice, but would delay the release for at least two weeks - not sure if I can get mgmt approval for that.

So what is your opinion (asking everyone - not just PEGR)? Delay the release to get PEGR's feature in? If delaying the release is not an option, what would your second choice be? Any other ideas?

 

Id like it delayed.

 

Hi Barb,


Even after adding "C:\Users\Public\Desktop.ini " as an exception folder, the AppGuard BETA is still blocking Windows Media Player from playing video files stored on my computer hard disk. [O.S.: Windows 7 Pro SP-1 32-bit]
I still see the blocking message stating: "Prevented process Windows Media Player from writing to C:\Users\Public\Desktop.ini" and blocking other locations that have to be accessed by WMP as well.

Couldn't AG developers look into this issue and see if they can come up with a solution, please?

Thanks,



Carlos

 

@Zyrtec

These are the WMP exceptions that I needed to add, though I'm on Win7x64 sp1:
c:\users\public\libraries\recordedtv.library-ms
c:\users\public\pictures\desktop.ini
c:\users\public\desktop.ini
c:\users\public\videos\desktop.ini
c:\users\public\music\desktop.ini

 

Stackz,

Thanks a lot buddy!

That was the problem. Based on my feedback, Barb mentioned that location only ["c:\users\public\desktop.ini"], because I only mentioned that one to her in my e-mail, unaware that other locations were being affected as well and hence, needed to be excluded.

Once I added the other ones you mentioned, the problem is gone.

But, wouldn't it be better if AppGuard allows WMP to access those locations by default without blocking it or, would it be a security risk if they are allowed by default?


Thanks.

 

Thanks!

 

It looks like delaying the release isn't going to be an option afterall. Our company is participating in a trade show next week and they wanted to unveil version 3.3 there. I did get the okay to include the enhancement in a quick follow on release. In the meantime, I think we are going to go with option 3.

 

Are you saying that this happens when you leave the power application in the MG exception list? Or is this true of all power applications (that certainly would be a bug)?

 

That would be nice!

 

We are considering having programs that are spawned by power applications automatically inherit the power (i.e. they would be power applications as well). What do you think?