Permit Once (Unable to Ask User)?

In the Security section, what is the implication of having a program with "Permit Once (Unable to Ask User)" as the last action? I looked in the Help section but did not see any explanation on this.

 

It means for whatever reason, ProcessGuard caught the execution but could not ask the user. This usually happens when you cannot display anything to the user for whatever particular reason.

You can change the "last action" to Permit Always or Deny Always, etc, to control what you want it to do after the fact.

 

Thanks Jason for your prompt response.

What would cause PG to be unable to issue its alert window to ask for permission? I see several entries in my Security section with this type of Permit Once.

This seems a bit scary in that a malicious program could make a change to a protected executable on hard drive and this change could sneak through with no human security alert that a change has occurred.

Example: I just upgraded Spy Sweeper 3.2 build 142 to build 148. Spy Sweeper restarted without any alert from PG. I have stopped Spy Sweeper, removed its entry from Security, restarted Spy Sweeper and no PG human alert. I have done this 4 times and it always ends up Permit Once (Unable to Ask User).

 

The only time it will happen is immediately on startup whilst there is a lot of congestion and before ProcessGuard has fully initialized. Whilst running the system there is no chance something "can get by".

The ProcessGuard service is running all the time, but the EXE which handles asking the user execution requests (pgaccount.exe) is only loaded when an account is started. So there is a small chance something could get by on startup before pgaccount.exe finishes loading, however it isn't reliable at all to do this and it firstly needs to add itself to the startup items which requires a running process. So even if something does manage to do this it still will be controlled as to what it can do according to the protections you have setup.

 

I am having a problem with Pgaccount.exe. It is not starting up on system reboot.

Am I correct in thinking that Pgaccount.exe has to be in memory all the time following a reboot?

Can you give me the exact registry entry for PGAccount so that I can check it? And should it be in Local Machine or Current User?

 

Should be in Local Machine (so it runs in every account) :-

Create a string value here :-
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

which should contain something like this (WITH QUOTES) :-
"C:\Program Files\ProcessGuard\pgaccount.exe"

Did you remove this entry or something?

 

And yes, pgaccount.exe should be running all the time so that ProcessGuard can handle execution requests.

 

Thanks,

My registry entry is correct as you stated. However, PGAccount.exe is not starting up on reboot. I have inspected it in msconfig-startup and it is checked for startup.

I can manually start up pgaccount.exe and it activates and stays in memory. And it gives the alert window as it should.

Something very strange here.

 

Yes that sounds very odd, I would just make sure the path is absolutely correct in the registry. Otherwise it should work fine.

 

I can move Pgaccount.exe to Startup Delayer and have it start 1 second into the reboot and it starts up okay. However, if it is in the RUN registry startup list, it will not startup. Other programs in this list are starting up okay.

 

This does seem like it is a security bug in PG if things seem to be all right on the surface; however, a critical program like pgaccount.exe is not running.

 

Well I found one small issue in pgaccount.exe which may stop it from loading in an extremely rare instance, the next version will be out soon with this fix in it. However it seems odd that you are the first person to report this, what are your system specs?

 

I am running XP-SP2 Home Edition, 2.66 ghertz P4, 1.5 gbytes DRAM, 80 gbyte HDD, Dell Dimension 8200.

Others may not notice it is not running because there is no visible evidence of it not running. The only reason I noticed it this AM is that I thought it was odd that a new build installation of Spy Sweeper did not generate any alert messages.

 

Doesn't this mean that some hacker, trojan, whatever, can modify/delete the RUN key for PGAccount.exe in the registry to prevent it from starting up on reboot and a hugh security hole opens up in PG. Protected programs can be modified on the hard drive and PG would accept them on next boot or program startup.

 

And there will probably be lots of "permit once (unable to ask user)" entries in the security list, but you're right, that's not something one frequently looks after....

Andreas

 

I will verify that in a moment, but I think that the PG service will prevent that from happening - PG protects a couple of registry keys as well.

Andreas

 

I certainly would not have seen it for awhile had I not gone looking. Plus there are users who do not use the GUI once they have things set up to their satisfaction.

 

Well, maybe I did not test it correctly, but I was able to modify that registry key. Didn't wait to see if it was restored after a while or at least before shutdown, tho. But as I know the other registry protections, I suppose even the modification shouldn't have been possible.

Andreas

 

The key can definitely be modified and deleted without any alert or corrective action by PG. Nothing is restored when the system is shutdown.

It would seem to me that all sorts of bells and whistles should go off if the PG driver finds this program missing from memory. It appears to be as important as dcsuserprot.exe once protection is enabled. JMO

 

That key is currently not protected, a decision will need to be made whether or should before the next version.

 

okay, then first let us get straight what can happen when the key is modified:

Firstly, the service is still running and so its current configuration will still apply. You only won't be able to use pguard.exe UI to view the log or to change the configuration - and you won't get Execution protection alerts. I suppose only the latter is much of an issue.

Then, you get no exec prot. alerts - but for those programs that have been defined in the security list, everything is working as usual (unless they are modified by, say, an update). And if you have enabled "Block new and changed programs", then you wouldn't get alerts anyway. The only vulnerability is for unknown or changed programs starting and being allowed once (unable to ask user). - Which still is a good enough reason IMHO to have the registry key protected.

Also, how would you go and change settings (à la "block new and changed programs") - is this possible after all or is it not when the UI doesn't find pgaccount.exe?

Finally, I'm not sure if pguard.exe wasn't at some point of the development able to take user-alerting over if it was active...

In case this has been not clear enough, I'm FOR a protection of that registry key,


Cheers,
Andreas

 

Block New and Changed works independantly of pgaccount.exe in most circumstances. The only time it won't is if there is a network file or EFS file that needs to be hashed but can't from the service session.

 

Jason,
that's (part of) what I meant to say. Good that you clarified it.

 

I question if many users can safely run with "Block New and Changed Programs" enabled.

Why? Because programs such as Norton programs frequently download and install program updates on the fly. And if a user has automatic updates enabled for such programs, this type of action would be blocked. Sure, it now requires user confirmation when a protected program module is hotfixed, but the hotfix is not silently blocked.

 

and I agree with that - I just wanted to have an exact picture of what works and what doesn't if pgaccount.exe isn't present.

Cheers,
Andreas