We use CATIA with several automotive partner environment packages. Our launcher provider requires ordinary users to have write access to the launcher folder, which also contains scripts and changes frequently.
That seems hard to reconcile with AppLocker, and hash rules would need frequent maintenance. Are there practical deployment options that keep the launcher usable without allowing execution from a user-writable folder?
The main issue is trusting a path where the same users can change the code. A path rule for that folder could allow a user to place or modify a script there and then run it under that rule.
Moving the folder under Program Files only helps if its permissions actually prevent ordinary users from modifying the executable content. The directory name alone does not fix it.
Ask the provider for a breakdown of exactly what needs write access and when. There may be a difference between user settings, temporary files, environment data and the scripts or launcher binaries themselves.
If those can be separated, keep the executable content in an administrator-controlled location and give users write access only to the data locations. Test each environment and utility after changing permissions, because the package may assume it can write back into its install directory.
y4+gearbox_918:
Updates are worth checking separately too. A launcher configured to overwrite its own files may need a different update process if users cannot write to the install folder.
If the files are signed, publisher rules may be easier to maintain than hashes as versions change. Check the actual launcher and scripts rather than assuming the whole package is signed, and test the rules against the components that need to run.
Signing is not a substitute for protecting writable files. The usefulness of a publisher rule depends on which files are signed and how the relevant AppLocker rules apply to them.
It may simply be a packaging limitation of the provider's launcher rather than a CATIA requirement. Ask for a supported deployment with managed updates and protected scripts, and document the security problem if they cannot offer one. That gives you something concrete to take into a risk review rather than quietly making a broad path exception.
Answers are reviewed before publication.
!brisk+as~bubbles:
That is the part we're stuck on. The provider says users need write access to the launcher and environment folder.