How to deny folder permission to Users with wix installer

Question

My goal is to install my application to a folder:

• readable and writable by SYSTEM
• readable and writable by administrators
• with no other permissions for anyone else.

I've tried various combinations and arrangements of the wix Permission and PermissionEx elements.

My latest attempt is this:

<CreateFolder>
  <util:PermissionEx User="Users" GenericRead="no" Read="no"/>
  <util:PermissionEx User="Everyone" GenericRead="no" Read="no"/>
  <util:PermissionEx User="Administrators" GenericAll="yes"/>
</CreateFolder>

inside a Component element.

My results are always the same: Users still show permission for Read, Read and Execute, and Listfolder contents on the installed folder.

My goal is quite similar to Restrict access to a folder installed using wix installer

I've also considered WIX: Giving Permissions to a folder and Wix: How to set permissions for folder and all sub folders.

Answer 1

I am just wondering what your overall goal is (several options could apply):

• Is the goal to prevent regular users from running the application? (if so, you could make elevation required for running - not great, but should work. Regular users would be asked for admin password on application launch. If they don't have it, they can't run the application - as far as I know - unless the admin account they elevate with has no password!).
• Is the goal to prevent regular users from being able to list the content of the actual folder in question? Replacing the ACL (disable inherited rights) and only adding access for the user / users / groups you want to be able to access the folder should do the trick. No deny rights or specific rights for regular users needed. In other words just replace the existing ACL and add generic write for Administrators and full rights for SYSTEM?

As I am sure you are acutely aware of, modifying ACLs can have many side effects, especially deny rights (what happens during self-repair?). I don't have time to test specific ACLs right now, but I will check again tomorrow if you still need it. I think the require admin rights option might work for you?

---

Quick Mock-Up

Just want to add a quick way to test permissions that I discovered. Just modify the ACL permissions as desired in Windows Explorer. Then launch an elevated command prompt and navigate to the folder whose ACL you want to capture. Then go:

cacls.exe foldername /s

This should show a SDDL string that you can dump straight in WiX to use the new, built-in LockPermissionEx table in MSI files (MSI 5 only!):

<Component Feature="ProductFeature">
   <File Source="Files\Test.exe" />
   <CreateFolder>
     <PermissionEx Id="p1" Sddl="D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a8;;;BU)" />
   </CreateFolder>
</Component>

The above should yield a folder that has full access for SYSTEM, Administrators and "special access" for regular users (traverse folder / run file, read attributes, read extended attributes, read access). As stated below this does not work too well since administrators generally run non-elevated and then impersonate regular users (not 100% sure how this really works).

As you know there are many, different WiX elements that relate to permissioning (mid page), and you can also use custom actions to do permissioning (not recommended). Going to test a little bit more tomorrow. Maybe a combination of an elevated EXE with a protected data folder could work? Or maybe a way to make the triggering shortcut invoke elevation before the system tries to launch the file it points to without elevation.

---

Trying to List Some Options

UPDATE: Not much testing done today, but I got thinking about the list of possible options. Some of these options are just jotted down and not really viable. They are in to rule stuff out and to see if they could spark new and better ideas. Maybe 8, 1, 2, 3 & 6 could be used? Maybe in combination?

Combo?: Super-hidden installation folder that is also ACL-locked and accessed by an always elevated EXE run from a mapped drive? (accessing an access-based enumeration server share?):

1. Lock / Hide & Elevate: hide sub folder with ACLs, then require UAC elevation on application launch by modifying the application manifest? A single launcher application EXE would be visible? (Can be super-hidden? See next bullet point).
   • Not great security-wise (once you elevate, access is pervasive), but I think it will work, and no regular user would be able to access the ACL-protected data sub-folder (they will see it though - but check out the next option with super-hidden folder status - combination possible?).
     • I will just mention that regular users will be asked for a password when trying to invoke executables that require admin rights to run. Without an admin password they can't run the application at all as far as I know. Can be forgotten in the heat of the moment, and a manager could miss that suddenly admin rights are required to run the application at all. I have seen it happen.
     • Though preventable by group policy for corporate networks, if there is a password-less, local administrator account (which could be common in small businesses), then any standard user can elevate to admin rights via that passwordless admin-account - at will - once prompted for an admin password.
       • Easy to forget.
       • Huge security hole.
       • There is the highest available elevation option that I have never tried (elevate to admin rights only for admin accounts, otherwise run with limited rights).
     • Not sure what happens if UAC is disabled. The whole approach probably fails? Or maybe it just runs elevated without asking? I don't know.
     • There are further security problems that are best not to mention along the same lines as any elevated process is problematic: access is pervasive and not specific ("all-access backstage pass" - unless you limit privileges well for the account).
     • Make no mistake about it: elevating EXE files should ideally only be used to allow system maintenance and configuration by system administrators who know what they are doing. Elevation has no place in good software engineering for regular corporate applications. In theory there should be no difference between theory and practice, but in practice there is :-).
   • You would likely need to keep the main application binary visible for it to be launchable by any users though. Otherwise MSI self-repair kicks in as the file pointed to is inaccessible. Maybe a custom shortcut flag is available to force elevation immediately? Going to have a look.

2. Make Folder Super-Hidden: this is probably a silly option. It depends on your use case and how protected these files must be? Are they just desired out of view, or do they have to be "locked" and inaccessible? You can set a super-hidden flag for your folder with a simple attrib command:

   attrib +s +h "C:\Folder\"
   

   The folder is now super-hidden like some core OS folders. Such a folder doesn't show up in Windows Explorer or in command line unless you take special steps to make it appear (show hidden OS files - see above link). But the folder is not locked for access if the users know the folder is there. Maybe you can combine the super-hidden flag with another approach? (hide the folder and lock it too?)

3. Access-Based Enumeration Server Share: this new server feature seems to be what you need actually. It hides folders that the user in question does not have access rights to, but I don't think the feature can be used on regular PCs (non servers). Perhaps it can? Something to check later. I don't know if storing files on a server share is an option or not?

   • You cannot configure NTFS permissions to hide files or folders from unauthorized users.
   • Access Based Enumeration in Windows Server 2016.
   • "Odd hack": Access Based Enumeration on Windows 7.
4. Database Connection: this is surely out of the question - for some reason - but the elephant in the room is why this data access (if it relates to data-access) isn't done via a database and an authenticated connection?
5. Web-Application: as with 4, a good reason obviously exists preventing you from making this a web-application? Or I guess it could be a web-application for all we know. Jotting down whatever comes to mind, bear with me.
6. Mapped Drive via Logon Script / Group Policy: I suppose you could use a mapped drive via a logon script (or better, using group policy) which is mapped only for the users who should have access to the application? Simple applications could run straight off such a mapped drive I think. No installation to do either. Or you keep a binary in the mapped drive, and the rest of the files locally?
7. NTFS symbolic link: trying to jot down everything that comes to mind as I said. I have never used this feature, but I know a NTFS symbolic link could point to a server share. What if that server supports access based enumeration? Would this hide the files and folders for some users? Unwise to list options you haven't tried, but maybe someone else gets a better idea reading it?
8. Custom NT Access Group: I am wondering if the simplest "fix" of all would be to create a local or AD access group which you need to be a member of to be able to access your folder at all. So you remove all built-in groups, add SYSTEM and your custom group with full access and any other groups that are technically needed (creator?). I haven't tested this (maybe it was the first thing you tried?). Combining such a local group with a super-hidden folder sounds like an option. No regular users will easily see the folder, and if they do they can't access it? There is still the issue of the launching shortcut visibility? (why should users see it, if they can't launch the application).

Answer 2

If you can locate (or create) a folder with the permissions you need, I would first use CACLS.exe to display the permissions in the SDDL format. Once you've got that, you can use the MsiLockPermissionsEx table in your MSI.

WiX doesn't seem to support the MsiLockPermissionsEx table directly, in the sense that there doesn't seem to be a way to just paste in an SDDL string to apply to something, unless I've missed it somewhere.