locked
SimulateSAS fails on Windows 7 RRS feed

  • Question

  • I am the developer for a product that uses the SasLib library to simulate a Secure Attention Sequence, and I have noticed that this feature of my product fails on Windows 7 systems, whereas the same binary succeeds on Windows Vista.

    My process is running as the SYSTEM account (as a child process of a Windows Service), and I verified that the appropriate software SAS generation policy is set to allow both Services and UiAccess processes.

    Has anyone else seen similar behavior or know of a solution?

    Thanks!
    Thursday, January 28, 2010 8:53 PM

Answers

  • The crux of the issue is that at some point after Vista shipped, either a Service Pack or an update, seems to have begun enforcing a stricter policy with regards to generating the SAS via software.

    There are two kinds of applications that can generate a SAS: Services and Ease-of-Access applications.

    1) In order for a Service to generate a SAS, the SoftwareGenerateSAS policy must be set to allow either Services or both Services and Ease-of-Access applications.  And you must statically link against the SasLib library (no longer being distributed) statically, or you must dynamically link against the sas.dll that is included in the Windows 7 SDK (and is redistributable).  Note that this DOES NOT APPLY to processes who are running as SYSTEM, but are not themselves Services (in my experience)

    2) In order for an Ease-of-Access application to generate a SAS, many other things have to happen.  First, your application has to have a manifest with the uiAccess field marked as "true". Second, your application has to be digitally signed.  Third, either your application must reside in a "secure" filesystem location or you must change the security policy to allow for Ease-of-Access applications to be executed from an "unsecure" filesystem location.  Fourth, your application must be started from the Shell, not CreateProcess (since CreateProcess doesn't seem to care about any potential manifests.  Those are the steps necessary to even get your application running.  The SoftwareGenerateSAS policy must also be set to allow either Ease-of-Access applications or both Services and Ease-of-Access applications.  You must also abide by the same linking rules as in the case where you are a Service.

    For my situation where I had a child process of a Service that was created with CreateProcess and running as SYSTEM, the Ease-of-Access route was not a real option.  My solution was to have a separate Service executable which linked against the necessary libraries, whose sole function is to execute a SAS.  I then installed a temporary it as a temporary Service (which you have to handle yourself).  The service simply calls the necessary function and then exits.

    I also decided to link statically against the SasLib since the other option was to redistribute the sas.dll form the Windows 7 SDK.  If you decide to take the redistribution path along with my solution, you can probably attach the sas.dll as a resource to your Service executable image, and then extract it at runtime before you use it (either with an explicit LoadLibrary or by having it delay-load).
    Thursday, March 18, 2010 6:11 PM

All replies

  • Hello

    I wonder whether SasLib is a library developed by third party? If yes, I believe that it's appropriate to involve the support group of the third party product into this incident.
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, January 29, 2010 6:01 AM
  • No, SasLib is a static library provided by Microsoft.  In order to obtain it, we had to send an email to saslib@microsoft.com.  I've seen other reports in message groups that indicate that the aforementioned email address has been unresponsive.  I have not tried it recently.  I will go ahead and send a message to that address to see if I get a response.  In the mean time, is there anyone else who might have any ideas?

    Friday, January 29, 2010 2:45 PM
  • Hello

    I notice this new API in Windows 7:
    http://msdn.microsoft.com/en-us/library/dd979761(VS.85).aspx

    My assumption is that this API deprecates the SimulateSAS function in saslib in Windows 7. Could you please try it and let me know whether it works for you?
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, February 1, 2010 6:37 AM
  • Hello

    How are you? May I know whehther the SendSAS  API helps you?
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, February 5, 2010 7:41 AM
  • The SendSAS API looks promising, however there is one issue that is immediately recognizable and another that still exists from the previous question.

    1) SendSAS is only available on Windows 7 and Windows Server 2008 R2 and above.  It appears that the SasLib static library was refactored so that the static lib (sas.lib) only contains link information and that the actual logic is implemented in a DLL (sas.dll) that ships with said Operating Systems.  That means that SendSAS will not work on Windows Vista and Server 2008.

    2) Even when using SendSAS, I've discovered that the uiAccess value in the application's manifest must be set to true, EVEN IF RUNNING UNDER THE SYSTEM ACCOUNT (unless you actually are a Service).  This is really unfortunate, because an application that is marked with uiAccess=true, will only start up correctly if it is signed and it is executed by the shell (via ShellExecute) and if it lives in a "protected" file system location (can be changed via the local security policy).  Does anyone know of a good reason that a process running as SYSTEM should not be allowed to execute this code?

    Sighs all around.

    Tuesday, March 2, 2010 3:15 PM
  • Hello

    Regarding your first question, the MSDN doc says the following :

    http://msdn.microsoft.com/en-us/library/dd979761(VS.85).aspx
    Windows Server 2008 and Windows Vista:  Sas.dll is not available natively. You must download the Windows 7 version of the Microsoft Windows Software Development Kit (SDK) to use this function. In addition, an application must refer to Sas.dll to call this function.

    If you have the SDK installed, you’ll find sas.dll in the following directory:
    C:\Program Files\microsoft sdks\Windows\v7.0\Redist\

    So you can redistribute the DLL located on the Windows 7 SDK as described in the documentation on MSDN.
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, March 3, 2010 1:18 AM
  • The crux of the issue is that at some point after Vista shipped, either a Service Pack or an update, seems to have begun enforcing a stricter policy with regards to generating the SAS via software.

    There are two kinds of applications that can generate a SAS: Services and Ease-of-Access applications.

    1) In order for a Service to generate a SAS, the SoftwareGenerateSAS policy must be set to allow either Services or both Services and Ease-of-Access applications.  And you must statically link against the SasLib library (no longer being distributed) statically, or you must dynamically link against the sas.dll that is included in the Windows 7 SDK (and is redistributable).  Note that this DOES NOT APPLY to processes who are running as SYSTEM, but are not themselves Services (in my experience)

    2) In order for an Ease-of-Access application to generate a SAS, many other things have to happen.  First, your application has to have a manifest with the uiAccess field marked as "true". Second, your application has to be digitally signed.  Third, either your application must reside in a "secure" filesystem location or you must change the security policy to allow for Ease-of-Access applications to be executed from an "unsecure" filesystem location.  Fourth, your application must be started from the Shell, not CreateProcess (since CreateProcess doesn't seem to care about any potential manifests.  Those are the steps necessary to even get your application running.  The SoftwareGenerateSAS policy must also be set to allow either Ease-of-Access applications or both Services and Ease-of-Access applications.  You must also abide by the same linking rules as in the case where you are a Service.

    For my situation where I had a child process of a Service that was created with CreateProcess and running as SYSTEM, the Ease-of-Access route was not a real option.  My solution was to have a separate Service executable which linked against the necessary libraries, whose sole function is to execute a SAS.  I then installed a temporary it as a temporary Service (which you have to handle yourself).  The service simply calls the necessary function and then exits.

    I also decided to link statically against the SasLib since the other option was to redistribute the sas.dll form the Windows 7 SDK.  If you decide to take the redistribution path along with my solution, you can probably attach the sas.dll as a resource to your Service executable image, and then extract it at runtime before you use it (either with an explicit LoadLibrary or by having it delay-load).
    Thursday, March 18, 2010 6:11 PM