Permission allocation and inheritance of software restriction rules in Windows Group Policy

For Windows Group Policy, perhaps everyone is using more of the features in the "Management Templates". For the "software restriction strategy" I believe that not many friends have used it.

If the software restriction strategy is good, I believe it can be compared with some HIPS software. If you combine NTFS permissions and registry permissions, you can fully implement the system's full security configuration. At the same time, because this is a built-in function of the system, it seamlessly integrates with the system, and does not occupy additional CPU and memory resources. The incompatibility phenomenon, because it is located at the bottom of the system, its interception capability is unmatched by other software. The downside is that its settings are not flexible and intelligent, and will not ask the user. Let's take a comprehensive look at the software restriction strategy.

This series of articles will focus on the following aspects:

·Overview
·Additional rules and security levels
·Priority of software restriction policy
· Rules Assignment and Inheritance
· How to Write Rules
· Example Rules

Today we introduce the rights allocation and inheritance of software restriction rules in Windows Group Policy.

One of the premise of the explanation here is: Suppose your user type is an administrator.

In the absence of a software restriction policy, if program a starts program b, then a is the parent of b, and b inherits the authority of a.

Now set a as the basic user, b does not limit (put b to be unrestricted or not set the same effect on b) and then start b by a, then the permission of b inherits from a, It is also a basic user, namely:

a (basic user)-> b (unrestricted) = b (basic user)
If b is set as the basic user, a does not limit, then a After starting b, b is still the basic user right, ie
a (unrestricted)-> b (basic user) = b (basic user)

can be seen, a program The final permissions that can be obtained depend on: the parent process permissions and the minimum level of the rules-defined permissions, which is what we call the minimum permissions principle.

For example:
If we set IE as a basic user When the level is activated, the permissions of any program executed by IE will be no higher than the basic user level and can only be lower. So you can achieve the effect of preventing the network horse - even if IE downloads the virus and executes it, the virus cannot make harmful changes to the system due to the permission restrictions. If you restart it, the virus will only have the dead body.

Even, we can also make IE unable to download and run the virus through the NTFS permission settings, without giving the virus any chance.

Here, let's take a look at NTFS permissions (the permissions here are NTFS permissions, regardless of the rules). All permissions of NTFS are as follows:
Traversing the folder/running the file (the traversal folder can be ignored, mainly "run file", if there is no such permission, the file cannot be started, which is equivalent to the running application of AD)
Allow Or reject a request that the user moves through the entire folder to reach other files or folders, even if the user does not have permission to traverse the folder (only for folders).

List Folder/Read Data
Allow or deny users the request to view file names and subfolder names in the specified folder. It only affects the contents of the folder, not whether the folder for which you set permissions is listed (for folders only).

Read Attributes
Ability to allow or deny viewing data in a file (applies only to files).

Read Extended Attributes
Allows or denies requests from users to view file or folder attributes such as read-only and hidden. The attribute is defined by NTFS.

Create File/Write Data
"Create File" allows or denies creating a file in a folder (for folders only). Write Data allows or denies the ability to modify files and overwrite existing content (applies only to files).

Create Folder/Append Data
"Create Folder" allows or denies the user's request to create a folder in the specified folder (for folders only). Append Data allows or denies the ability to make changes to the end of a file without changing, deleting, or overwriting existing data (files only).

Write Attributes
Allow or deny users the ability to make changes to the end of a file without changing, deleting, or overwriting existing data (files only). Write operation.

Write extended attributes
Allow or deny users requests to change file or folder properties such as read-only and hidden. The attribute is defined by NTFS.

Deleting subfolders and files
Allows or denies the ability to delete subfolders and files, even if no "delete" permissions are assigned to subfolders or files (for folders).

Delete (the difference from the above is that in addition to the subdirectory and its files, it also includes the directory itself)
Allow or deny users the request to delete subfolders and files, even subfolders or files There is no "delete" permission assigned to it (for folders).

Read Permissions (View of NTFS Permissions)
Allows or denies requests from users to read file or folder permissions (such as Full Control, Read, and Write).

Change Permissions (Modification of NTFS Permissions)
Allow or deny users the ability to change file or folder permissions (such as Full Control, Read, and Write).

Take ownership
Allow or deny ownership of a file or folder. The owner of a file or folder can always change its permissions regardless of the existing permissions used to protect the file or folder.

Under the default NTFS permissions of the system, the basic user only has to traverse the folder/run file, list the folder/read attribute, read the extended attribute, and read the right for the windows\\program files directory. Permissions, for the documents and settings directory, only have full control over all of its directories, other directories are read-only?

The basic users and restricted users mentioned in our rules are basically equivalent to the USERS group in NTFS permissions, but restricted users are subject to more restrictions, regardless of NTFS permissions, they are always subject to limit.