Critical System Protection

Hi,

I would like to know if it would be possible to block programs from being removed from add-remove programs in control panel. I would still like to provide view access to the programs installed. The second question is can I alert on attempts to uninstall software from servers? i believe this falls under detection policies. Any assistance would be appreciated.

The servers in questions 2003-2008r2 & it wouldnt hurt to know if this will work in server 2012.

How would i allow a particular product access to msiexec to install programs or patches with keeping the restriction in place?

Can i also specify *.* at the end of the value to detect all changes in add/remove programs?

You only need one asterisk - that covers 1 more more characters, including spaces and special characters.

I am still researching how to get what you want -- apparantly, you cannot pull msiexec.exe out of the svc_safepriv_ps to give it custom controls, you can only make it not start by sending it to sev_nopriv_ps by adding it to the list of services that cannot start.

I am researching on how to get the same results in the add/remove programs that you see with SCSP when self protection is enabled.

More to come . . . .

Do you have an update on this?

Actually, this may be a change that needs to be made to the policy source code . . . . Other customers have run into the same limitation.  May be a few days until I get an answer from Engineering on this.

Chuck,

Have you made any progress on this case?

All of the uninstall information for applications are kept in the registry in

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
and (if you are running a 64 bit OS)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

If you open these keys and look at all the entry values, you will see the applications that are installed on the system.

If you block ALL access to these Uninstall keys or one of it's subkeys (per application), you will not be able to uninstall the application from Add/Remove programs, because it will not be listed in add/remove programs.

You mentioned that you want to have access to the list in add/remove programs, but still block the ability to remove the application.  For that, I would not allow the Windows Installer service to start:

Service Options > Alternative Privilege Lists > Specify Services that should not start > %systemroot%\system32\msiexec.exe 

That will allow you to still view the list of installed apps, but not allow any applications that depend on the Windows Installer service to be removed.  It also will not allow anything to be installed.  Note that this should be tested in your environment and tuned properly, because certain processes or services may depend on this (like SCOM, or other 3rd party patching tools).  It may be necessary to further tune the policy to allow tools like this to start msiexec.exe.

To alert using detection, you would want to either rely on the IPS policy above to alert you, or use detection to monitor creation/modification/deletion of the

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall*

registry keys.

[Edit:  Grammer, added 64bit OS]

Please note that I edited my fist comment to include the 64bt OS registry key that will also need to be blocked.  32 bit applications that are installed on a 64 bit OS are placed in the Wow6432node registy branch.

If you can get the product to run as a particular user, you can use the username in the rule.  So, if the process was running under "system" it would be blocked, but if it were run under the user "trusted installer" then you can give it safe privileges.

You can also use the arguments section to differentiate when an is placed into Full, Safe, Standard or No-Privilege. 

So, add msiexec to the program path in "Services that should not start", then edit the msiexec.exe line in  "Services with Safe Privileges" to include an argument and/or a username.  You will have to edit the Windows Installer service in services.msc to run under a particular user if you are going to go that route.

Chuck I have tried adding this policy entry: Service Options > Alternative Privilege Lists > Specify Services that should not start > %systemroot%\system32\msiexec.exe

I was still able to install wireshark & remove wireshark from this server with the above policy entry.

Chuck can you clarify this a little?

"If you can get the product to run as a particular user, you can use the username in the rule. So, if the process was runing under "system" it would be blocked, but if it were run under the user "trusted installer" then you can give it safe privilages."

Ultimately when prevention is enabled we do not want any admin to be able to do the following:

1. Install any software

2. Remove any existing software

Did you stop and attempt to start the Windows Installer service after applying the policy?  CSP does not stop running processes, it just prevents them from starting.

For clarification, you can assign processes to PSETs by using the username for the assignment criteria. Same with arguments.   Services run under a user (usually system).  You can change what user the services run under, and use that as a criteria for assignment to certain process sets.

Or, if you know the arguments that will be passed to msiexec.exe, you can very granularly control that behavior. 

Also, make sure you remove the msiexec.exe from the safe priv section of the alternative privilege list.

CSP, when there is a conflict (where the same executable is placed in 2 sections of a process set), will use the LEAST restrictive one.

Chuck,

if i remove msiexec.exe from the safe privileges group, how can grant access to a particular program to have safe privileges to msiexec.exe?

Do it by username or arguments.  So, in Safe Priv, take msiexec.exe, and add the argument the program will use or the username that the program will run under. If the argument and/or username do not match, then CSP will assign the msiexec.exe to the no-priv group (or whatever group that you put msiexec.exe without the additional info into).

See https://www-secure.symantec.com/connect/articles/csp-command-line-arguments-matching-and-troubleshooting for more info on argument use.