AppLocker implementation

What is your opinion about the predefined rules for Windows installers AppLocker creates?

They are:

Allow Everyone %systemdrive%\Windows\Installer (Path rule)
Allow BUILTIN\Administrators All Windows Installer files (Path rule)

and one more, which actually comes first

Allow Everyone All Windows Installer files with valid digital signature (Publisher rule)

I wonder why would it create this latter rule? Makes any sense for you? I mean, if I want to allow, say the latest Adobe Reader update installer which is an .msp file, I'll just create a rule for it. Why a global rule allowing such?

What are your thoughts?

 

Hi m00nbl00d,

I don't mind those default installer rules; the latter Publisher rule is fine by me because Publisher rules can be, imo, trusted without reserve, especially if - and this is important - these rules are generated on a new, clean installation, which is a highly recommended approach to implementing AppLocker in the first place. However, defaults are generally recommended to be used only as a starting point, but if one (the administrator in this case) is careful about what's added afterward, then there should be no problems.

 

Absolutely!

Yes, indeed, they're only recommended to be a starting point, but - and this is my opinion - it beats the purpose that standard users shouldn't be able to install anything without administrator consent.

Considering that AppLocker is "targeted" at enterprise level, in my opinion, the predefined rules should prevent a standard user from installing/running anything without previous authorization. This happens for executable and script rules, but not for Windows installer rules.

In my way of seeing it, it is just a convenience? I truly don't see the lack of that specific rule I mentioned to cripple anything, except for preventing a standard user from installing/updating some application, which should be what AppLocker should be aiming. Administrators may as well just delete that rule, but I wonder why Microsoft decided to make it a predefined one... I guess is one more thing that I don't understand from Microsoft. lol

 

Yes, you make all good points for sure. I guess the way MS looks at it is their own Publisher signed installer files won't harm anything, even if standard users can launch them The only additional logic I can of for this "liberalness" is that maybe there are a few cases where it's necessary for even the standard users to have full priviledges to Windows installer filess?? I'm only hazarding a guess here, of course.

 

That beats me just like you; I wonder why they would need such permissions, though? I can't see day-to-day standard user tasks that would demand such permissions.

As a little test, I deleted that rule and waited a few seconds so that AppLocker applies it. I downloaded the Microsoft EMET installer, which is an *.msi installer; obviously now a standard user fails to run the installer.

With Adobe Reader updater, which is an *.msp installer, the standard user is able to execute it. So, this rule as no effect in this specific situation, where you're applying updates to applications already installed in system; or - and this is a wild guess - the updater interacts with some Adobe executable/executable type, and this is the process that actually starts the update installer, hence being allowed. Again, a very wild guess as I haven't monitored this; so don't take it for granted.

Obviously, installing EMET or any other app which install using Windows Installer to %ProgramFiles% dir would deman admin. rights; but they may as well install to user space instead, and the problem is if this installer is infected. This is why I can't possible understand this Microsoft decision. I see it dangerous, specially nowadays that more malware is writing to user space, instead of machine level. Every angle should be taken into account, and this is one.

 

-Edit-

Nothing bad has happened, so far, by having removed the rule from AppLocker predefined rules. Only great things - a standard user won't be able to install applications that use Windows installer.

I still have to figure out why I was able to update Adobe Reader, though. Not entirely sure what happened behind the scene; will have to check it in a virtual machine, where Adobe Reader isn't updated and monitor what happens. I don't like the fact that a standard user is able to update applications using Windows Installer (.msp).

 

For anyone interested in a typical ruleset - including both executable and DLL rules - for Google Chrome browser (latest version), they are posted in the screenshots attached. They are a collection of Publisher and path rules (mostly Path). Note the wildcard entries so that they apply to all users, and in the case of covering "dynamic" (changing) directories. It was like pulling teeth getting these configured

 

Isn't it because you allowed ADOBE at the publisher level?

Same subject: Allowing globally GOOGLE is not enough?

 

Or one can install Google Chrome in system level either via enterprise installer or google pack.
This way your default programm files rule solve problems with executables. Cant remember dll
hovewer you will need to give admin permissions to manulaly update google chrome in the future.
Auto-update should work fine as sceulded updated by default runs as admin if I am not mistaken.

 

My goal is to simplify things, if possible, with Publisher rules directed at the user's Appdata directories, thereby eliminating or at least reducing the Path rules. I don't want to allow globally simply because my interest is to restrict as much as possible to specific directory paths.

 

Sorry, I was not precise enoug:

Setting up a Google publisher rule to allow its executables and DLL should be enough to get rid of any problem except if Chrome install sets up EXEs or DLLs which are not signed...

So what are the path rules for?

 

No, I have not.

It's just AppLocker design. By design, it will allow installation of Windows Installers, both *.msi and *.msp, because they're digital signed.

But, this only happens if the rule to allow installation outside of %systemdrive%\Windows\Installer (Path rule) and
BUILTIN\Administrators All Windows Installer files (Path rule) is set in place.

The rule that allows such is Allow Everyone All Windows Installer files with valid digital signature (Publisher rule)

If this latter rule is kept, then a standard user will be able to install to user-space, for example Google Chrome, which installs to user-space by default.

If this rule is removed, then this no longer happens, except for *.msp installers. But, AFAIK, this type of installer only installs if a given application is already installed, like in this case Adobe Reader.

I still couldn't give a more in-depth testing. I can't bother myself with it, in times to come. More important stuff to do.

-edit-

The *.msp installers won't only install to user-space. They will install to system level, just like what happens with Adobe Reader updates.

There is an interaction of some sort with an object already installed, with privileges enough to start the updating process. I say of some sort, because as mentioned, I didn't check what truly happens.

 

Right, that might work and it's my next approach.

Because I didn't apply Publisher rules to the Appdata directories yet.

*EDIT*

okay, so I applied Publisher rules to the Appdata directory and below, and it seems to work fine. Note the two Hash rules for the wow_helper.exe and chrome_frame_helper.exe because they're not signed files.

@Lucy, if you come with another idea, please post it. It's always interesting to see what others are doing.