Search code examples
windows-installermanifestapp-certification-kitinstallshield-2013

Windows App Certification Kit run fails Windows Security Best Practices

I'm using the App Certification Kit to verify a very small installation package which I've built with InstallShield 2013. The "Attack Surface Analyzer" is failing its test with an error message that the installation directory

...contains files and/or folders with ACLs that allow tampering by multiple non-administrator accounts.

It then reports that my three install files have "bad ACL's... Writable by: Builtin Users Rights: FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, FILE_WRITE_DATA"

The installation requires none of those rights, and I haven't specified anything off the defaults for the components, except to disable automatic COM detection for both components. In earnest, this thing is supposed to equate to an "XCopy" type of deployment.

What do I need to look for to pass the Attack Surface Analyzer test to pass with a simple MSI installation like this?

The installation consists of:

One Feature, containing two Components:

  • My main EXE, which is a 64-bit .NET compiled applicaiton
  • the EXE's external .manifest file

The second component contains:

  • A 64-bit COM DLL intended for registration-free execution by only this application

The .manifest file contains only working registration-free COM server data, pointing at the DLL: 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

  <assemblyIdentity name="MyAssembly" version="1.0.0.0" 
                    type="win32" processorArchitecture="amd64"/>

  <file name="MYsideBySide.dll">
    <comClass
       (working comClass stuff) />

    <typelib
       (working typelib stuff) />
  </file>    

     <comInterfaceExternalProxyStub 
          (working ProxyStubStuff) />
</assembly>
Solution

  • The installation package was configured to install onto a directory that, for the test, already existed. Apparently a previous installation had set inheritable rights on that directory.

    When I changed the install package's destination path (the INSTALLDIR variable), the Attack Surface Analyzer test passed. As is ever so common with these kinds of things, a different package of software interfered with normal operation.