The "minimalist" approach to PG usage.

Discussion in 'ProcessGuard' started by spy1, Feb 3, 2004.

Thread Status:
Not open for further replies.
  1. spy1

    spy1 Registered Member

    Dec 29, 2002
    Clover, SC
    1. One who advocates a moderate or conservative approach, action, or policy, as in a political or governmental organization.
    2. A practitioner of minimalism.

    1. Of, relating to, characteristic of, or in the style of minimalism.
    2. Being or providing a bare minimum of what is necessary.

    IMO, ProcessGuard is a program whose main thrust, or objective, is to stop malicious things from happening to - primarily - your most important defensive-type programs (anti-virus, anti-trojan, anti-keylogging, firewall) and any anti-scumware (AdAware, SpyBotS&D,etc.) programs or "fixing" tools you may have (such as CWShredder, for example), as well as certain critical system-type exe's (the most important of which are already included in PG as the default when setting the program up - always make sure you accept those for addition).

    By "malicious things", I mean that you don't want those types of programs
    (a) stopped from running when you click on them
    (b) unable to scan when they do open
    (c ) rendered unable to fix or clean things they find
    (d) rendered unable to be updated or
    (e) flat-out terminated as a running process if they're running resident to begin with (in SYSTRAY, for example).

    Now, once you do get the exec's of these types of programs into PG's "Protected processes list", some of them are probably going to "want" things, as shown by the entries in either the "Windows Log" or the "File Log" in PG - this is where the "minimalist" approach comes in.

    The primary question you should ask yourself before granting any non-default privilege to a program in PG's list is this:

    Do I absolutely HAVE to "allow" this action for this program to work correctly? Because if you don't, you shouldn't!

    Every single thing you "allow" un-necessarily (or don't set to "on" - checked - in PG's "General Protection Options" field) waters-down PG's effectiveness and potentially will create vulnerabilites where there were none using the default settings and all General Protection Options!.

    Log entries may be a pain-in-the-butt to go through, but you need to realize that they're absolutely vital for understanding what to watch out for and what the programs you add actually NEED to function.

    If you have a program which you absolutely trust, but which drives you nuts with log entries, you have a couple of options:

    If the program does not run "resident" (running all the time with Windows), you can either simply

    (a) disable both logging fields in PG when you run it or

    (b) shut PG down altogether when you do run it. (Remember - we're talking about a program that you absolutely trust!).

    NOTE: - I wouldn't trust any program after either a major update or a version-change - I'd default everything back on that particular program, use all "General Protection Options" and see what's happening since the changes.

    If the program does run "resident" (all the time) - you've got the same decision to make - "Do I absolutely trust this program?" "Will this program that I absolutely trust NOT run correctly if I don't give it such-and-so "Allows" - or dis-able this-or-that protection?"

    Only after you've answered both of those questions affirmatively should you even think about changing default program settings or dis-abling protections.

    Which brings me to my final point (aren't you glad? :D ) - we really don't need to be throwing everything-and-the-kitchen-sink into PG's "protected processes" list, folks - it's both counter-productive and guarantees you configuration-related problems, decisions and issues.

    Unless any given program IS definitely known to be subject to malware/scumware-related termination or injection-related attacks, or it keeps showing up in your logs as needing this-or-that (and thus you HAVE to deal with it through PG) don't bother to add its' exe to PG's list - it's POINTLESS!.

    So, gang, what do you think? Pete
  2. DolfTraanberg

    DolfTraanberg Registered Member

    Nov 20, 2002
    Here I have a different opinion. If you have a trusted program protected by PG you should give it all privileges it asks for. I don't think you should change the way a program is working.
  3. Pilli

    Pilli Registered Member

    Feb 13, 2002
    Hampshire UK
    Hi Pete, Nice discussion points :)

    One of the important thing to remember is that on individual processes "Allows" ONLY apply to other listed i.e protected programmes, these are not global and therefore it is safe to allow. IMO this should always be kept in mind.

    In general I agree with your minimilist approach, keep the default settings and perhaps add Close Message Handling as an extra precaution, be careful though and do it systematically so that if you get a problem it is much easier to back track and correct.

    The same with adding other .exe's, do one at time, starting with those programmes that are allowed access to the world through your firewall, your Anti virus & Anti Trojan apps Watch the logging, make the necessary changes. Watch for any detrimental effects. If for instance a non - listed programme is trying to hook a listed programme that you trust it, add it to the list.

    Process Guard is a very new and innovative programme, there will be anomalies but I am sure these will be overcome.
  4. nameless

    nameless Registered Member

    Feb 23, 2003
    I really tend to agree. How do you know that a given application "really needs" something, such as the ability to create and use a global hook? Easier said than done. For example, I run a Hauppauge TV tuner, and its software uses a global hook. Should I deny it? Oh sure--but TV tuner software runs in kernel mode. This means that messing with it may not be the best idea in the world.

    Will denying it this or that privilege crash my system? I don't know in the case of the TV tuner software, but I can tell you that when I had full-bore, ultra-paranoid Process Guard protection in place, my system was unpredictable and unstable. When I backed it off, things improved. How would I have backed it off "just enough"? That's the clincher.
  5. Jason_DiamondCS

    Jason_DiamondCS Former DCS Moderator

    Nov 11, 2002
    Perth, Western Australia
    I think there are issues with Block Services/Drivers AND Block Global Hooks are causing issues for some people in v1.200, simply untick those protections and it should work just as well as earlier versions.

    v1.250 increases compatibility and stability with these 2 options enabled.

Thread Status:
Not open for further replies.