AppGuard 4.x 32/64 Bit - Releases

I added C:\Sandbox with read/write.

 

Did you install Sandboxie in your D: drive ? By default all other partitions are considered user space. You have to add the Sandboxie folder to user space tab and set the include flag to 'No'.

 

Yes, Sandboxie is installed on drive D: I already added the folder to user space but didn't set the include flag to no. that's why it didn't work. now everything is fine. Thanks

 

Well yes, to clarify, I´m not saying that those apps are better than AG, but IMO they are easier to understand. And it might be my imagination but AG´s approach seems to be causing problems for quite a lot of people.

And you´re wrong about MBAE, it provides protection out of the box without causing much problems. That´s mostly because it´s protecting only apps that are vulnerable to zero day attacks. Also, I still wonder if AG´s memory protection is as advanced as in MBAE and EMET?

 

Regarding a normal Sandboxie install, under C:\Program Files\Sandboxie, a 2 step procedure is needed to have the drive by protection from AppGuard:
AppGuard 4.x 32/64 Bit

Add c:\sandbox as an exception folder with Read/Write access in the Guarded Apps->Settings... and also add c:\sandbox with a Yes Include flag in the User Space tab.
Without the latter you won't have driveby protection from AG.

Then when you want to install a program inside a sandbox, you will have to do from AG system tray: Allow User Space Launches. AppGuard 4.x 32/64 Bit

I posted this so as no misinformation might get spread when mixing Sandboxie install folder with Sandbox container folder. That No in your post might otherwise get interpret wrong by casual readers.

It would be preferable yes to shut down your computer and reboot before an install with regarding memory malware when AG is not protecting as far as I understand.

 

Folders on other drives are user space by default and, depending on AppGuard's protection level, anything trying to launch from there will either be guarded or cannot launch at all. In case of Sandboxie's own processes neither is desired. You further have to considered that Sandboxie's installation folder will not be protected from being written to by guarded apps in that location. You might want to add the installation folder to guarded apps with deny access or read only.

 

Or should not have installed Sandboxie in the user space in the first instance.

 

No, I wouldn't have installed Sandboxie in user space.

 

The distinction between system-space and user-space is emphasised because system-space and user-space folders have to have different write and launch permissions in order for AppGuard drive-by download protection to work.

What is unnecessarily complicated is not the way AppGuard works, but rather the GUI. I believe the way the tabs have been implemented (especially the User Space tab) are responsible for much of the confusion that users experience, judging by the number of questions at Wilders that relate to customising folder permissions via the GUI.

Adding a folder to the User Space tab and setting the Include flag to Yes gives the appearance that the folder is now in User Space. But this is only partially true. In terms of the permissions that apply to user-space folders, the folder is not fully in user-space unless it has also been added as an Exception Folder in the Guarded Apps tab. This is not only misleading, but also means that the folder has to be added twice (in two different tabs) to move it from system-space to user-space.

Similarly, adding a folder to the User Space tab and setting the Include flag to No gives the appearance that the folder is no longer in user-space. Again, this is only partially true. In terms of the permissions that apply to system-space folders, the folder is not fully in system-space unless it has also been added as a Protected Resource in the Guarded Apps tab. This also means that the folder has to be added twice (in two different tabs) to move it from user-space to system-space.

The reason I am repeating this is to reinforce the point that it is the GUI that is complicated, not AppGuard itself. AppGuard is like a standard (limited) account with enhanced features, with the added advantage that AppGuard provides protection even if the user is logged on as administrator. I don't think that's hard to understand, but the GUI could do with improvement to simplify things and make it more intuitive.

But that's exactly how AppGuard works. Applications are either guarded (restricted) or unguarded (trusted).

Both AppGuard and classical HIPS work by the application of policy, but AppGuard is an out-of-the box approach to policy building whereas classical HIPS is more of a DIY approach.

With AppGuard, the policies are pre-defined, with different policies applied to trusted and untrusted applications. Because AppGuard policies are pre-defined by the security experts at BRN, there is no need for the user to be alerted to make decisions about what to allow and deny, as there would be with a classical HIPS. AppGuard silently blocks all events that violate policy.

With classical HIPS, the policy is custom made, built from the ground up piecemeal by the user answering alerts on different types of monitored events as they occur. This allows for greater granularity and control, but is also more complex for the average user. If the user answers an alert incorrectly, security may be weakened as a result.

Neither approach is better, per se, but each will appeal to different types of user. Average users who may not be confident in answering HIPS alerts, and those advanced users who want their security software to operate silently in the background, may prefer AppGuard. Advanced users who are confident answering HIPS alerts and who want the additional control to define their own policy may prefer classical HIPS.

AppGuard isn't an anti-exe, because it doesn't use whitelisting, although it has some anti-exe features in relation to user-space. With AppGuard, it isn't possible to prevent applications running from system-space; the best you can do is to guard them. With an anti-exe, only applications on the whitelist are allowed to run, so there is no fundamental distinction between system-space and user-space in terms of what can be controlled via the whitelist. Also, an anti-exe doesn't usually apply further restrictions to running processes once they've been allowed to start.

Whether AppGuard is a behaviour blocker, depends on how the term is defined. The term is sometimes used to describe applications that block behaviour based on an assessment of badness, usually by scoring suspcicious behaviour and alerting if a threshold value is exceeded (e.g. ThreatFire). AppGuard isn't a behaviour blocker in that sense. If the term is widened to include any application that blocks behaviour based on policy violation then AppGuard could be described as a type of behaviour blocker, as could classical HIPS also.

 

Yes, Pegr's post are always very informative.

 

Thanks guys.

 

Yes indeed, thanks for the informative post.

I guess it´s sometimes just a matter of: you either get it, or you don´t. I also think that the GUI perhaps should be improved a bit. But from what I´ve understood, AG is mainly meant to protect against drive by attacks. I prefer other tools to achieve that goal, but that was already clear, I suppose.

 

As a stubborn continued user of XP, I have several key components in my layered security. AG is among the keyest of the key, second only to my imager program.

 

I found this blocked event in my AG activity report. Has anyone else been seeing this in their activity report. I think it was caused by the adobe flash plugin because it was blocked at the same time. I know my adobe flash plugin has been crashing recently when watching online videos. It has been causing Firefox to freeze. I did remove Adobe as a trusted publisher about a month ago. I'm wondering if it could have been an attempted drive by download because I was watching one of those fake hocks videos about a shark that was not real. Anyways I'm not sure how bootsqm.dat could be used to manipulate one's machine. I'm looking into it now. It could have likely been as well.

 

bootsqm.dat has nothing to do with Adobe Flash Player. Its created whenever you run the disk error check. Its harmless and you can delete the file.
The problem you are experiencing with Flash Player is something else.

 

That's not what i'm saying. I'm asking if it would make any sense for a drive by download using adobe flash to write to bootsqm.dat? I saw a description of the bootsqm.dat online, but i'm wondering if it would make any sense for malware to target writing to that file to use it maliciously. After looking at description online it does not seem like it would be a good target for malware writers.

 

I don't think drive by download, will write to bootsqm.dat file.. and the parent process in your case is services.exe.. clearly flash is not involved..

 

Ok, thanks you.

 

We've been reflecting on this as well to try to come up with better terminology. What we call user-space is the area of the file system that can be written to by non-admin users. The OS does not really protect that area of the file system and thus programs are permitted to write to those folders as well (so they are a prime target for malware). That is why AppGuard restricts applications in that area - either by completely blocking (Locked Down) or Guarding digitally signed applications (Medium). Would "Application-Restricted Space" (quite a mouthful) or "Data Space" be better terms? Any ideas?

 

Not really. I do like the existing terminology (system and user space) that also IMO reflect what people would imagine them to mean. AppGuard's policies have to be explained in a concise manner, using some concepts and those are not too abstract for anyone to grasp if taken some time.

Same time a basic user does not really need to understand (I myself have to reread sometimes) all the stuff to be protected.

 

IMO existing terminology is perfect and I don't recommend any changes to it.

 

I would not recommend changing the terminology. I think it is fine the way it is.

 

Couldn't agree more. The descriptions make perfect sense to me.

I guess it might not be an issue is with the naming convention but rather the concept of how the product works that some are struggling with. Is it people don't understand the whole trusted/untrusted enclave thing? If that is indeed the issue I don't know what changing the description will do.

Read Pegr's excellent description referenced elsewhere and if you aren't getting it maybe this is not the product for you. Changing the names won't help IMO.

AG has a strong reputation because of its solid protection and simplicity. Trust what has got you this far. The pendulum is swinging and products like AG are the future IMO.