Windows App Certification Kit run fails Windows Security Best Practices

Question

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>

Can you say where the files are installed? If it's complaining about folders it might help to say where the files are installed. Security may be inherited from the folders. — PhilDW, Jul 16 '14 at 20:56
See my answer. It was, in fact, related to the destination folder for the three files, which in the failing test already existed. — Rob Perkins, Jul 17 '14 at 21:21

score 0 · Accepted Answer · answered Jul 17 '14 at 21:20

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.

Windows App Certification Kit run fails Windows Security Best Practices

1 Answers1