none
Software Restriction Policies and Installers That Use Temp folders.

    Question

  • We use SRP's with certificate rules and they work quite well.  However, a number of software publishers (I'm looking at you, Autodesk) will sign their main MSI/installer file, but then the installation process tries to run unsigned executables in Temp folders, which, of course are blocked.  This is especially annoying for program updates/patches because I either have to disable the SRP to install the updates or add hash rules for all the unsigned executables.

    Has anyone found a workable/safe solution or have any advice?


    --Bill

    Friday, March 25, 2016 9:21 PM

Answers

  • Has anyone found a workable/safe solution or have any advice?

    What method/mechanism are you using to perform/execute the deployment (installation)?

    If you're using a "trusted" deployment mechanism, and, if that mechanism uses the LOCALSYSTEM account/principal - SRP shouldn't be applicable?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    • Marked as answer by bdaly Monday, April 04, 2016 12:27 PM
    Wednesday, March 30, 2016 8:59 AM

All replies

  • You may try discuss this with software vendors and they might have alternative solution for deployment and update.
    Saturday, March 26, 2016 4:17 PM
  • Hi,

    To help you better, I will help to move this to GP forum for further discuss.


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Tuesday, March 29, 2016 2:53 AM
  • Hi,

    Thanks for your post.

    In my opinion, you should contact software vendors to get the temp folders' locations for software installation executables and add these paths and make them unrestricted so that program patches/updates can be installed.

    It is also appreciated that the other members in our forum can share their experience with us about this scenario.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, March 29, 2016 6:44 AM
    Moderator
  • @Alvin Wang,

    There are two problems with specifying the temp folder locations.  First it provides a well known unprotected location for malware to run.  For example, if malware writers know that everyone needs to exclude %USERPROFILE%\AppData\LocalLow\Oracle\Java from SRPs because Oracle doesn't sign all their Java updates, then this is where they are going to install their malware.

    Second, the temp folders are often randomly named, so they can't really be added to SRP path rules anyway.  There are many installers that execute unsigned EXEs from folders with names like %USERPROFILE%\AppData\Local\Temp\RarSFX643ad32e\.  It would be a huge risk to exclude \RarSFX* and similar paths from the SRP.

    I can't be the first one to run into these issues with SRPs, so I'm wondering what everyone else does.  For the more common freeware type software, I use Ninite Pro.  However, the other less common software that comes with its own update mechanisms will often be blocked.  I doubt that people are individually contacting every software publisher to put together a solution, so what is everyone else doing?


    --Bill

    Tuesday, March 29, 2016 12:48 PM
  • Hi Bill,

    Thanks for your reply.

    It is appreciated that the other members in our forum can share their experience with us about this scenario.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, March 30, 2016 7:23 AM
    Moderator
  • Has anyone found a workable/safe solution or have any advice?

    What method/mechanism are you using to perform/execute the deployment (installation)?

    If you're using a "trusted" deployment mechanism, and, if that mechanism uses the LOCALSYSTEM account/principal - SRP shouldn't be applicable?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    • Marked as answer by bdaly Monday, April 04, 2016 12:27 PM
    Wednesday, March 30, 2016 8:59 AM
  • Don, I do use Ninite Pro for keeping certain software updated (e.g. GIMP, 7-zip, Dropbox).  These updates can be run from a service account.

    However, there are a number of apps that have a built-in update system that either run from within the end-user application (e.g. ICPR from streamnologies.com) or that use a separate "update" app that runs as the user and not as a service (e.g. Autodesk Application Manager).  In both cases the end user has to initiate the update, but the unsigned updates won't run from a temp folder.  I would have to login separately as an administrator unaffected by the SRP in order to run the updates.

    The solution, according to the documentation on most apps, is simply to exclude the user profile folders from the SRP and/or give the user local administrator access.  This basically defeats any security mechanisms I have in place.


    --Bill

    Wednesday, March 30, 2016 6:12 PM
  • Ah, auto-updaters...

    I don't have a suggestion for that scenario, sorry.
    We don't grant our users local-admin rights, we package and deploy basically everything, via ConfigMgr (which runs as localsystem), and we disable auto-updating in the apps wherever possible (since they would only succeed if the vendor includes a service-based updater agent).

    I agree with the expectation that these vendors should either sign everything, or provide a manageable service-based updater agent, for those who don't use enterprise deployment management systems.

    Even Configmgr wizardry sometimes struggles with some of the Autodesk product suite weirdness :(


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Wednesday, March 30, 2016 7:54 PM