Everybody writes to program files!

Now and then I am given a program to deploy that doesn't work. Just kidding, I get such programs all the time.

Actually, I am quite surprised when something works straight out of the box. I have a hard time fathoming how people without my amazing skills get anything to work on their computer at all.

Well, one of the reasons is that most people are using their home computers with an account that has administrative privilegies. Some people even turn off UAC to get rid of some annoying consent-dialogs.

In a corporate environment, this is a very very bad idea. Ask anyone working at an Iranian nuclear facility. (Full disclosure: I don't have a clue about the infrastructure at any nuclear facility, Iranian or otherwise).

A very common problem I face is programs that require write-permissions in its program folder. Older programs, binaries that does not include a manifest with a requested execution level, have their writes redirected by modern Windows to the users profile, to %localappdata%\VirtualStore. This, however, only works with UAC enabled.

But so far so good, these old crap program works somewhat, thanks to the pile of workarounds that is Windows.

New crap programs does not.

They are getting less and less common but I still get them.

Why not just give users write-permissions, you may ask. Because they don't deserve it I may answer, but that would be wrong. No, it's because it's a major security concern.

Having write access to program or system folders is different than having write access anywhere else, because a malicious program could replace files the user launches, and unlike executables saved on the desktop or the download folder, users don't have a clue what they are launching when starting an already installed program.

Also, it makes further security restrictions like AppLocker a pain to administer. Imagine you manage a restricted environment where users are only allowed to start prior approved programs, that you have tried, tested and deployed. The users are not local administrators, so they can't install anything, and you wan't to configure AppLocker so that they can't even start binaries but the programs you deploy.

Pretty much the only AppLocker rules you would need then are the default rules, like this one:

While this isn't entirely true if you use stuff like Click-to-Run, ClickOnce (stupid names, by the way) or AppV, it covers most of what you need.

However, if only ONE folder that fits within your Allow-rules are writable by users, it all falls apart! Any user or a malicious program can then launch whatever they want, and the added security AppLocker is supposed to provide is to no avail.

Microsoft has a tool, Sysinternals AccessChk that will help you after the fact, but you will need to be the person to avoid installing programs that changes permissions on folders.

If you absolutely MUST, install the program elsewhere. Not in the root directory, but maybe in C:\ProgramData or make a new folder called C:\Program Files Secure.

Or why not C:\Program Files That Suck!

Then you'll need to add new AppLocker rules separately. But it works.