AppLocker - Deny application for everyone except specific AD group

[CHiLL]

We are looking at deploying a CCTV viewer/exporter to our pastoral devices, so they can view/export footage without having to come through us. However, we have found that the software we need to use stores all it's configuration (including credentials and connection details) in "C:\Users\Public". This exposes an issue where if the software is installed on a pastoral staff laptop and someone else who isn't a pastoral member logs on, that person will have the same access to the CCTV.

 

Ideally, I'd like to use something like AppLocker or Software Restrictions to state that only members in the "Pastoral" security group can launch the application. I'm struggling to wrap my head around how to manage this, since deny policies override allow. By default, everyone has access to the application because it's installed in "C:\Program Files (x86)". If I put an allow for the specific pastoral group, it doesn't do anything because they (and everyone else) already has access to it. If I put a Deny for all users (or the all staff group) and an allow for pastoral, the deny takes precedence.

 

Since we have a redirected start menu and desktop icons, I could just manage access to the shortcut using file permissions, but I don't want to risk it being opened another way and the person having access.

 

Can anyone help me wrap my head around it?

[jthompson]

Wouldn't AppLocker's default rules prevent your users from executing anything in "C:\Users\Public" anyway? If so, all you would need is a rule to allow your pastoral group to run the CCTV app.

[psydii]

Use a GPO to explicitly set the ACLs on the CCTV sub folder inside the Public and Program Files folders -

 

*Block inheritance* for the Public\CCTV and the Program Files\CCTV folders

Then set permissions on that folder to mirror those of "Program Files" except instead of "Users R+X" have CCTV_USERS R+X" For the Program Files\CCTV folder have an additional ACE of CCTV_USERS (W)

 

The inheritance block will remove the Users permissions to even enter the folder and see config files or other data that may further expose the system. Applocker not needed in this case.

 

The other "correct" way of doing it is to exert explicit control over *EVERYTHING* installed on a machine. No blanket "Program Files - ALL USers Allow" applocker rule, but instead have rules per folder (i.e. per application installed). This is a lot of work, and slows down software deployments and trips up automatic updates when they decide to change folder names.You'd need two security groups for each application app_AppName_allow, and app_appname_deny

Then for each application you deploy you have two rules:

AppFolder - app_AppName_Allow (allow)

App Folder - app_AppName_Deny (Deny)

 

Typically Domain Users would be a member of app_AppName_Allow and app_AppName_Deny would be empty.

 

In the scenario above you'd make the pastoral team group a member of app_CCTVSoftware_allow, and remove Domain Users.

 

The deny group would only come into use if you needed to block access to only a subset of users (for example Students, or Yr12)

Edited April 19, 2024 by psydii

[CHiLL]

Wouldn't AppLocker's default rules prevent your users from executing anything in "C:\Users\Public" anyway? If so, all you would need is a rule to allow your pastoral group to run the CCTV app.

Users are reading the config, not executing since it's only the config files in the C:\Users\Publlic folder and the application is in C:\Program Files (x86).

 

Use a GPO to explicitly set the ACLs on the CCTV sub folder inside the Public and Program Files folders -

 

*Block inheritance* for the Public\CCTV and the Program Files\CCTV folders

Then set permissions on that folder to mirror those of "Program Files" except instead of "Users R+X" have CCTV_USERS R+X" For the Program Files\CCTV folder have an additional ACE of CCTV_USERS (W)

 

The inheritance block will remove the Users permissions to even enter the folder and see config files or other data that may further expose the system. Applocker not needed in this case.

 

The other "correct" way of doing it is to exert explicit control over *EVERYTHING* installed on a machine. No blanket "Program Files - ALL USers Allow" applocker rule, but instead have rules per folder (i.e. per application installed). This is a lot of work, and slows down software deployments and trips up automatic updates when they decide to change folder names.You'd need two security groups for each application app_AppName_allow, and app_appname_deny

Then for each application you deploy you have two rules:

AppFolder - app_AppName_Allow (allow)

App Folder - app_AppName_Deny (Deny)

 

Typically Domain Users would be a member of app_AppName_Allow and app_AppName_Deny would be empty.

 

In the scenario above you'd make the pastoral team group a member of app_CCTVSoftware_allow, and remove Domain Users.

 

The deny group would only come into use if you needed to block access to only a subset of users (for example Students, or Yr12)

Aaah, I forgot about using GPO to set permissions, specifically under "Computer Configuration > Policies > Windows Settings > Security Settings > File System".

 

The following groups have the following permissions to that folder:

ALL APPLICATION PACKAGES = Read and Execute, List Folder Contents, Read
Creator Owner = Full Control
SYSTEM = Full Control
MACHINE\Administrators = Full Control
MACHINE\Users = Read and Execute, List Folder Contents, Read

 

Since permissions effectively work on a "if you're not on the list, you're not getting in", couldn't I just replace "MACHINE\Users" with "Domain\PastoralGroup" and also grant the same permissions? I could also repeat that for the "C:\Program Files (x86)" application folder. That way no other user can access it unless they're in the group. When I selected the folders from my machine, it states that inheritance is already off and sub files/folders inherit from that object. Or rather it gives me the option to turn inheritance on...which I take to mean it must already be off for me to be able to turn it on.

 

I've created a test policy that I'll try out on Monday.

Edited April 19, 2024 by CHiLL