Protecting files and shared folders

Subject information security today it is more popular than ever. IT professionals gain knowledge from everywhere: from special magazine articles and even from daily email newsletters.

Most technical means protect the organization's resources from outside interference. But it is often necessary to share access to information within the enterprise itself. Just imagine the problems that could arise if all employees had access to the personal records of their colleagues.

The NTFS file system in Windows XP and its shared folder permissions are specifically designed to protect the contents of shared folders from both internal and external leaks. This article provides several tips that will help an administrator competently assign NTFS permissions and control access to shared folders and files.

File access control

Most users upload files to open access for members of working groups and p2p networks, for this you need:

Enter a name for the folder in the Share Name field.
If desired, you can add a few explanatory words in the Comment column.
Click OK.

However, this method does not always work correctly, especially on Windows XP systems with NTFS-formatted disks (when conflicting NTFS permissions come into conflict, preventing authorized users from accessing these resources; more on this below). Well, the saddest thing is that the default permissions set in Windows XP give access to the contents of directories to all users.

Also, in order to assign different permissions to different users, you must disable the default Windows XP Simple File Sharing option. general access to files):

Open Windows Explorer
Go to the Tools menu
Select Folder Options
Go to the View tab.
In the Advanced Settings window, uncheck the Use Simple File Sharing (Recommended) | Use simple file sharing (recommended).
Click OK.

To disable permission for Everyone and configure the access level for each user individually:

Full Control permissions allow users or groups to read, modify, delete, and run files contained in a folder. In addition, such users can create and delete new subfolders in this directory.

Users who have the right to change information in a folder (Change) can view and change files in the directory, create their own files and folders in it, and run programs located in it for execution.

Users and groups with Read permissions are only allowed to view files stored in the directory and run programs. For information on Windows disks XP formatted with the NTFS file system, you can set additional permissions.

NTFS permissions

NTFS permissions in Windows environment provide an additional set of parameters that can be configured for each individual file or folder.

First you need to make sure that Windows settings XP allows you to work with the NTFS file system:

Click Start
Select Run
Enter compmgmt.msc in the line and click OK. The Computer Management console opens.
Go to the Disk Management object on the Storage tab to find out what type file system used on every disk.

If the disk or one of its partitions is not formatted in NTFS, this can be corrected by entering convert X: /fs:ntfs, replacing X with the letter the desired disk or section. The convert command will change the current disk file system to NTFS without destroying the data stored on it. However, it is better to back up the contents of the disk before running the command.

To configure NTFS permissions:

Please note that by default, subdirectories inherit the properties of their root directories. To change this, click the Advanced button on the Security tab of the Properties dialog box.

Types of NTFS permissions:

Full Control- allows users and groups to perform any operations with the contents of a folder, including viewing files and subdirectories, launching application files, managing the list of folder contents, reading and running executable files, changing the attributes of files and folders, creating new files, adding data to files, deleting files and subdirectories, as well as changing access permissions to files and folders.
Modify- Allows users and groups to view files and subdirectories, run executable application files, manage the list of folder contents, view folder settings, change the attributes of folders and files, create new files and subdirectories, add data to files and delete files.
Read & Execute- Allows users and groups to view a list of files and subdirectories, run executable application files, view the contents of files, and change the attributes of files and folders.
List Folder Contents- Allows users and groups to navigate through directories, work with a list of folder contents, and view the attributes of files and folders.
Read- Allows users and groups to view the contents of a folder, read files, and view attributes of files and folders.
Write- allows users and groups to change the attributes of files and folders, create new folders and files, as well as change and supplement the contents of files.

To determine the final permissions of a user, subtract from the NTFS permissions granted to him directly (or as a member of a group) any individual denials (or denials that he received as a member of a group). For example, if a user has Full Control to a given folder, but at the same time is a member of a group for which Full Control is denied, then as a result he will not have Full Control rights. If a user's access level is limited to the Read & Execute and List Folder Contents options in one group, and at the same time they are denied access at the List Folder Contents level, then as a result NTFS permissions will be limited to the Read & Execute level only. For this reason, administrators should approach prohibitions with extreme caution, since prohibited functions take precedence over those allowed for the same user or group.

Windows XP is equipped with a convenient utility for confirming the current permissions of a user or group:

Combining NTFS permissions with sharing permissions

Sounds promising. It would seem that it is enough to correctly distribute the appropriate powers to users - and you can start working. However, in reality it is not so simple. Sharing permissions and NTFS permissions should clearly define what actual access rights users and groups have, but unfortunately they often conflict with each other. To determine the final permissions of a particular user, compare the resulting sharing permissions with the resulting NTFS permissions. Remember that access restrictions will dominate permissions. For example, if a user's resulting NTFS access rights are limited to the Read and Execute level, and the resulting public access rights are limited to the Full Control level, the system will not grant that user actual Full Control rights, but will choose the highest priority level, in this case it is NTFS read and execute permission. It is always necessary to remember that the resulting restrictions in rights prevail over the resulting permissions. This is very important point, which is easily forgotten and then causes a lot of trouble for users. Therefore, carefully calculate the ratio of prohibitions and permissions of NTFS permissions and general access

Using NTFS permissions, we can differentiate the rights in a folder in more detail. We can prohibit a certain group from changing a certain file, leaving the ability to edit the entire main file; in the same folder, one user group may have edit rights on one file and will not be able to view other files edited by another user group and vice versa. In short, NTFS permissions allow us to create a very flexible access system, the main thing is not to get confused in it later. In addition, NTFS permissions work both when accessing a folder over a network, complementing public access permissions, and when local access to files and folders.

There are six basic permissions, which are a combination of 14 advanced permissions.

BASIC PERMISSIONS:

Full control– full access to a folder or file, with the ability to change access rights and audit rules for folders and files
Modify– the right to read, change, view the contents of a folder, delete folders/files and run executable files. Includes Read and Execute, Write and Delete.
Read and execute (readandexecute)– the right to open folders and files for reading, without the ability to write. It is also possible to run executable files.
List of folder contents (listdirectory)– the right to view the contents of the folder
Read– the right to open folders and files for reading, without the ability to write. Includes Folder Contents / Read Data, Read Attributes, Read Extended Attributes, and Read Permissions
Write– the right to create folders and files, modify files. Includes Creating Files / Writing Data (writedata), Creating Folders / Appending Data (appenddata), Writing Attributes (writeattributes) and Writing Extended Attributes

ADDITIONAL PERMISSIONS

Folder traverse / file execution (traverse)– the right to run and read files, regardless of folder access rights. The user will not have access to the folder (what is in the folder will remain a mystery), but the files in the folder will be available via a direct link (full, relative or UNC path). You can put on the folder Traverse folders, and on the file any other permissions that the user needs to work. The user will not be able to create and delete files in the folder.
Folder contents / Read data (readdata)– the right to view the contents of the folder without the ability to change. You cannot run or open files in the folder you are viewing
Reading attributes– the right to view the FileAttributes of a folder or file. You cannot view the contents of a folder or files or change any attributes.
Reading additional attributes (readextendedattributes)– the right to view additional attributes of a folder or file.
Creating files / writing data (writedata)– gives the user the ability to create files in a folder to which he does not have access. You can copy files to a folder and create new files in the folder. You cannot view the contents of a folder, create new folders, or change existing files. The user will not be able to change any file, even if he is the owner of this file - only create it.
Creating folders / adding data (appenddata)– gives the user the ability to create subfolders within a folder and append data to the end of the file without changing the existing content.

This article discusses in detail how to use the Xcacls.exe program...

This article details how to use Xcacls.exe (Extended Change Access Control List tool) to view and change NTFS permissions for files and folders.
Using Xcacls.exe, you can set all security settings for a file system that is accessed from the command line in Explorer (Xcacls.exe displays and modifies file access control lists (ACLs) for this purpose).
It is recommended to use Xcacls.exe for automatic installation Windows 2000 Professional or Windows 2000 Server. With its help, the initial access rights are set for the folders in which the operating system files are located. In the process of transfer software on servers and workstations, Xcacls.exe provides one-step protection against user deletion of files and folders.
The Xcacls.exe program is included in the package Windows 2000 Resource Kit. In the center Microsoft downloads The following file is available:

Collapse this imageExpand this image

Syntax of Xcacls.exe

xcacls filename ] ]

where filename is the name of the file or folder to which the list or access control is typically applied. Any standard wildcard characters can be used.
/T Recursively scan the current and all subfolders, assigning the specified permissions to all files and folders that meet the requirements.
/E- edit the access control list (without replacing it). For example, after running the command XCACLS test.dat /G Administrator:F, only the administrator account has access to the Test.dat file. Any previously applied access controls are canceled.
/C- Xcacls.exe continues to run even after receiving an "Access Denied" message. If the parameter /C is not specified, the appearance of this message causes the program to stop.
/G - user:permission;special_access Give a user access to a specific file or folder.

The permission variable is used to assign specified access rights to files and define a special file access mask for folders. The resolution variable takes the following values:
- R- reading
- C- change (write)
- F- full access
- P- change permissions (special access)
- O- change of owner (special access)
- X- launch (special access)
- E- reading (special access)
- W- recording (special access)
- D- deletion (special access)
The special_access variable (special access) is used only with folders; takes the same values as the resolution variable, plus the following special value:
- T- value undefined - assign an access control element to a directory without specifying the element that is used for files created in this folder. At least one access right must be specified. Text between the semicolon (;) and the T parameter is ignored. Notes
  - Access parameters for files (for folders - special access to files and folders) are identical. For detailed descriptions of these options, see your Windows 2000 documentation.
  - Other settings (also assigned in Explorer) are subsets of all possible combinations of basic permissions. For this reason, there are no special folder permissions (such as LIST or READ).

/R user Revoke all access rights for the specified user.
/P user:permission;special_access- change access rights for the specified user. The "permission" and "special_access" variables are defined according to the rules described for the /G parameter. See section of this article.
/D user- deny user access to a file or folder.
/Y- Cancel the prompt to confirm changes in access rights. The CACLS program displays this prompt by default. For this reason, if the CACLS command is used as part of a batch file, its execution is interrupted before the response to the request is received. Parameter /Y used to suppress the prompt window when using Xcacls.exe in batch mode.

Using Xcacls.exe to View Permissions

You can also use Xcacls.exe to view file and folder permissions. For example, at the command prompt, type xcacls C:\winnt and press ENTER. Typically the program returns the following result.

C:\WINNT BUILTIN\Users:R BUILTIN\Users:(OI)(CI)(IO)(special access:) GENERIC_READ GENERIC_EXECUTE BUILTIN\Power Users:C BUILTIN\Power Users:(OI)(CI)(IO)C BUILTIN\Administrators:F BUILTIN\Administrators:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:F NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F BUILTIN\Administrators:F CREATOR OWNER:(OI )(CI)(IO)F

The ACL flags have the following meaning.

IO: Inherit Only (inheritance only) - this element access control is not applied to the current object.
C.I.: Container Inherit - This access control is inherited by lower level containers.
OI: Object Inherit - This access control is inherited by lower level files.
NP: Non-Propagate - The lower-level object does not propagate the inherited access control.

The letter at the end of each line indicates resolution. For example:

F- full access
C- change
W- recording

Examples of using Xcacls.exe

Example 1

To replace the ACL for all files and folders in the current folder without viewing the subfolders and prompting you for confirmation, type XCACLS *.* /G administrator:RW /Y at the command prompt, and then press ENTER.

Example 2

The access controls added in this example also inherit the access controls of new files that are created in the folder. After entering this command, TestUser has the right to read, modify, run, and delete all files that are created in this folder, but only has read and write permission for the folder itself. At the command prompt, type XCACLS *.* /G TestUser:RWED;RW /E and press ENTER.

Example 3

This example sets read and write permissions on a folder without creating an inheritance element for new files. For this reason, for the TestUser, files created in this folder are not assigned an access control. An access control with read permissions is created for existing files. At the command prompt, type XCACLS *.* /G TestUser:R;RW /E and press ENTER.

Instructions for assigning NTFS permissions

When assigning NTFS permissions, consider the following:

NTFS permissions control access to files and folders.
It is advisable to set permissions for groups rather than individual users.
File permissions take precedence over folder permissions.
Administrators and the object owner control permission assignments.
When changing folder permissions, be mindful of the programs that are installed on the server. Programs create their own folders for which the parameter is set Transfer permissions inherited from a parent object to this object. Changing permissions on a parent folder may cause problems with programs.
Warning. Many folders and files gain permissions through inheritance. Therefore, changing permissions on one folder may affect other objects.

Why in most cases does an organization need a server? Active Directory, RDS, print server and a bunch of other small and large services. The most visible role to everyone is perhaps the file server. People work with him, unlike other roles, most consciously. They remember which folder contains what, where scans of documents are, where their reports are, where faxes are, where shared folder, in which everything is possible, where only one of the departments has access, where to another, and they have no idea about some of them at all

I want to talk about access to network and local folders on the server.

Access to shared resources on the server is carried out, as everyone knows very well, using the SMB 3.0 protocol. Network access to folders can be limited by SMB and NTFS permissions. SMB permissions only work when accessing a shared folder over a network and do not have any effect on the availability of a particular folder locally. NTFS permissions work both over the network and locally, providing much more flexibility in creating permissions. SMB and NTFS permissions do not work separately, but complement each other, according to the principle of the greatest restriction of rights.

In order to share a folder in Server 2012 in the SMB Share Cmdlets group, the New-SMBShare cmdlet has appeared. Using this cmdlet as an example, we will see all the options available when creating a shared folder, except for cluster configurations (this is a separate big topic).

Creating a new shared folder looks very simple:
net share homefolder=s:\ivanivanov /grant:"admin",full /grant:"folderowner",change /grant:"manager",read /cache:programs /remark:"Ivanov" or
new-smbshare homefolder s:\ivanivanov –cachingmode programs –fullaccess admin –changeaccess folderowner –readaccess manager –noaccess all –folderenumerationmode accessbased -description "Ivanov"

Let's figure it out:

-name is the name of the shared folder on the network, which may differ from the name of the folder on the local computer. It has a limit of 80 characters and the names pipe and mailslot cannot be used.

Path is the path to the local folder that needs to be shared. The path must be complete, from the root of the disk.

Cachingmode configures the autonomy of files in a shared folder.

What is an offline file?

An offline file is a copy of a file located on the server. This copy is located on your local computer and allows you to work with the file without connecting to the server. When connected, changes are synchronized. Synchronized in both directions: if you have made changes to your offline file, the next time you connect, the file on the server will be changed; if someone made changes on the server, then your local copy will be changed. If changes occur in both files at once, we get a synchronization error and will have to choose which version to save. I wouldn’t use this feature for collaboration, but if we create a ball for each user and limit access for others to reading, without the ability to write, we get the following benefits:

The work does not depend on the network - the switch may burn out, the server may reboot, the wire may break or the access point may turn off - the user works with his copy without noticing that you have some kind of accident there, when the network connection is restored, his work goes to the server.
The user can work anywhere: in the country, on a bus, on an airplane - in those places where a VPN connection is unavailable for some reason.
Even if the user is working via a VPN, but the connection is either very slow or constantly dropping out, it is easier to work with an offline copy and synchronize changes than to try to do something on the server.
The user can choose what and when to synchronize, if given the opportunity.

Accepts the following values:

none – files are not available offline; access to the files requires access to the server
manual – users themselves choose the files that will be available offline
programs – everything in the folder is available offline (documents and programs (files with extension *.exe, *.dll))
documents – documents are available, the program is not available
branchcache - caching instead local computer user occurs on BranchCache servers, users themselves select offline files

-noaccess, -readaccess, -changeaccess, -fullaccess share permissions.

These permits have one big advantage - they are very simple.

Noaccess secretary,steward – the secretary and the caretaker have nothing to do in the shared folders of the accounting department
-readaccess auditor – the auditor who checks the work of the accounting department can see the names of files and subfolders in the shared folder, open files for reading, and run programs.
-changeaccess accountant – accountants in their shared folder can create files and subfolders, change existing files, delete files and subfolders
-fullaccess admin – fullaccess is readaccess+changeaccess plus the ability to change permissions.

When you create a shared folder, the most restrictive rule is automatically applied - the Everyone group is given read permission.

These permissions apply only to users who have access to the shared folder over the network. At local entry into the system, for example in the case of a terminal server, both the secretary and the supply manager will see everything they want in the accounting department. This is fixed by NTFS permissions. SMB permissions apply to all files and folders on the share. More fine tuning Access rights are also provided by NTFS permissions.

Concurrentuserlimit Using this parameter, you can limit the maximum number of connections to the shared folder. In principle, it can also be used to restrict access to a folder, supplementing NTFS permissions, but you just need to be sure of the required number of connections.

Description A description of the shared resource that is visible in the network environment. Description is a very good thing that many people neglect.

Encryptdata encryption

In SMB before version 3.0, the only way to protect traffic from the file server to the client was a VPN. How to implement it depended entirely on preference system administrator: SSL, PPTP, IPSEC tunnels or something else. In Server 2012, encryption works out of the box, as usual local network or through untrusted networks, without requiring any special infrastructure solutions. It can be enabled for the entire server or for individual shared folders. The encryption algorithm in SMB 3.0 is AES-CCM, the hashing algorithm replaced HMAC-SHA256 by AES-CMAC. Good news is that SMB 3.0 supports hardware AES (AES-NI), the bad news is that Russia does not support AES-NI.

What are the risks of enabling encryption? Because only clients that support SMB 3.0, that is, Windows 8, will be able to work with encrypted shared folders. The reason, again, is the maximum permissible restriction of user rights. It is assumed that the administrator knows what he is doing and, if necessary, will give access to clients with a different version of SMB. But since SMB 3.0 uses new encryption and hashing algorithms, traffic from clients with a different version of SMB will not be encrypted, a VPN is needed. The command set-smbserverconfiguration –rejectunencryptedaccess $false will help you allow all clients to connect to a file server with encryption enabled.
In the default configuration (unencrypted traffic to encrypted shared folders is prohibited), if we try to access a client folder with an SMB version lower than 3.0 on the client, we will receive an “Access Error”. On the server, event 1003 will be added to the Microsoft-Windows-SmbServer/Operational log, where you can find the IP address of the client that attempted to gain access.

SMB and EFS encryption are different things that are in no way related to each other, that is, it can be used on FAT and ReFS volumes.

Folderenumerationmode This is Access-Based Enumeration. With Access-Based Enumeration enabled, users who do not have access to the shared folder simply will not see it on the file server and there will be fewer questions about why I don’t have access to this or that folder. The user sees his accessible folders and does not try to meddle in other people's affairs. The default is disabled.

accessbased – enable
unrestricted - turn off

-temporary This switch creates a temporary shared folder, access to which will be terminated after the server is rebooted. By default, permanent shared folders are created.

NTFS permissions

There are six basic permissions, which are a combination of 14 advanced permissions.

Basic permissions

Full control– full access to a folder or file, with the ability to change access rights and audit rules for folders and files

Modify– the right to read, change, view the contents of a folder, delete folders/files and run executable files. Includes Read and Execute, Write and Delete.

Read and execute (readandexecute)– the right to open folders and files for reading, without the ability to write. It is also possible to run executable files.

List of folder contents (listdirectory)– the right to view the contents of the folder

Read– the right to open folders and files for reading, without the ability to write. Includes Folder Contents / Read Data, Read Attributes, Read Extended Attributes, and Read Permissions

Write– the right to create folders and files, modify files. Includes Creating Files / Writing Data (writedata), Creating Folders / Appending Data (appenddata), Writing Attributes (writeattributes) and Writing Extended Attributes

Additional permissions

I set only 1 of 14 permissions on a folder and saw what happened. In the real world, in most cases, basic permissions are enough, but I was interested in the behavior of folders and files with the most reduced rights.

Folder traverse / file execution (traverse)– the right to run and read files, regardless of folder access rights. The user will not have access to the folder (what is in the folder will remain a mystery), but the files in the folder will be available via a direct link (full, relative or UNC path). You can put on the folder Traverse folders, and on the file any other permissions that the user needs to work. The user will not be able to create and delete files in the folder.

Reading attributes– the right to view the FileAttributes of a folder or file.
You cannot view the contents of a folder or files or change any attributes.

Reading additional attributes (readextendedattributes)– the right to view additional attributes of a folder or file.

The only thing I could find about additional attributes is that they are used to provide backward compatibility with OS/2 applications. (Windows Internals, Part 2: Covering Windows Server 2008 R2 and Windows 7). I don't know anything else about them.

Creating files / writing data (writedata)– gives the user the ability to create files in a folder to which he does not have access. You can copy files to a folder and create new files in the folder. You cannot view the contents of a folder, create new folders, or change existing files. The user will not be able to change any file, even if he is the owner of this file - only create it.

Creating folders / adding data (appenddata)– gives the user the ability to create subfolders within a folder and append data to the end of the file without changing the existing content.

Examination

Everything is clear about creating subfolders: ni c:\testperms\testappend –itemtype directory will work as expected - it will create a testappend subfolder in the testperms folder, which is inaccessible to the user. Let's try to add a line to the end of the file - let's simulate some kind of logging. newevent >> c:\testperms\user.log Access denied.
Hmm... It doesn't work in CMD. And if so. ac c:\testperms\user.log newevent ac: Access denied to path "C:\testperms\user.log".
What about the conveyor belt? "newevent" | out-file c:\testperms\user.log -append out-file: Access denied to path "C:\testperms\user.log".
And it doesn't work that way.

Let's start a session of black magic: use the File class, AppendText method. We get the log object.
$log = ::appendtext("c:\testperms\user.log") Exception when calling "AppendText" with "1" arguments: "Permission denied at path 'c:\testperms\user.log'."
I think AppendAllText is no longer worth trying
$log = ::appendalltext("c:\testperms\user.log","newevent") Exception when calling "AppendAllText" with "2" arguments: "Permission denied at path 'c:\testperms\user.log' "
The point is, in principle, clear. Only the above methods do not have the right to add data to a file; they need to write to a file. But at the same time, we will give the opportunity to change the file, and not just add records, that is, we open up the potential opportunity to destroy the entire contents of the file.

We need to reconsider the concept: let's not receive a log object, but create a new one in which we will set all the parameters that interest us. We need something where we can explicitly specify access rights. We need FileStream, and more specifically, FileStream Constructor (String, FileMode, FileSystemRights, FileShare, Int32, FileOptions) will help us. The following parameters are needed:

The path to the file is clear
How to open a file - open the file and find the end of the file
File access rights - adding data
Access for other FileStream objects - not needed
Buffer size – default 8 bytes
Additional options - no

It turns out something like this:
$log = new-object io.filestream("c:\testperms\user.log",::append,::appenddata,::none,8,::none)
Works! We have created a log object, let's try to write something there. The FileStream.Write method accepts incoming values in bytes. We convert the event that we want to record into bytes - the Encoding class, the GetEncoding method (we don’t need gibberish on the output) and GetBytes (actually, conversion)
$event = "A new event has occurred." $eventbytes = ::getencoding("windows-1251").getbytes($event)
FileStream.Write parameters:
What to write; where to start writing; number of bytes to be written
We write down:
$log.write($eventbytes,0,$eventbytes.count)
Let's check.
gc c:\testperms\user.log gc: Access denied to path "C:\testperms\user.log".
Everything is fine, the user does not have rights to view what has been written. Log in as administrator.
gc c:\testperms\user.log A new event has occurred.
Everything works.

The folder in which the file is located, in addition to the Create folders / add data permission, must also be granted the Folder Contents / Read Data permission. The file is only enough to create folders / add data with inheritance disabled. It will not be possible to completely protect the user (and the user can also be an attacker) from the files in which he should write something, but on the other hand, apart from the list of files in the folder, the user will not see anything and will not be able to do anything.

The conclusion from this is simple: you won’t be able to implement secure logging of anything in batch files; PowerShell saves you the ability to work with .NET objects.

Write attributes– allow the user to change the attributes of a file or folder. Everything seems simple. But just to answer the question: “Photos of my cats take up almost all the space on my profile and I have no room left for business correspondence. I would like to compress the folder with cats, but they ask me for administrator rights. You said that I have the right to change folder attributes. Is this an attribute? Why can't I change it?

Yes, a user with write attribute permission can change almost all visible attributes of files and folders, except compression and encryption attributes. Technically, the user is given the right to execute the SetFileAttributes function. And file compression is performed by the DeviceIOControl function, to which you need to pass the FSCTL_SET_COMPRESSION parameter, and file compression is far from its only job. With this function we can manage all the devices and their resources in the system and probably giving the user this right to perform this function means making him an administrator.

With encryption, the story is similar: the EncryptFile function, which is responsible for encryption, requires that the user have the rights Contents of Folder / Read Data, Create Files / Write Data, Read Attributes, Write Attributes and Synchronize on an Object. Nothing will work without them.

Write extended attributes. Well, these are the ones that are used for backward compatibility with OS/2 applications, yeah. Well, Trojans (ZeroAccess.C) have recently begun to be added to the extended attributes of the file C:\Windows\system32\services.exe. Maybe it’s worth turning them off at the highest level? I can’t answer this question; theoretically, maybe it’s worth it; practically, I haven’t tried it in production.

Deleting subfolders and files. (deletesubdirectoriesandfiles) An interesting permission that only applies to folders. The idea is to allow the user to delete subfolders and files in the parent folder without giving Delete permission.

Let's say there is a product catalog into which users enter data. There is a parent folder Catalog, inside there are subfolders in alphabetical order, from A to Z, with some names inside them. Names change every day, something is added, something changes, something becomes outdated and outdated information needs to be deleted. But it won’t be very good if someone, out of ignorance or malicious intent, destroys the entire K directory, which is very possible if users have the Delete right. If you take away the Delete right from users, then the administrator can safely change his job, because he will be fulfilling requests to delete this or that name all day long.

This is where Deleting subfolders and files comes into play. Inheritance is disabled for all letters of the alphabet and the Delete subfolders and files right is added to users. As a result, users will not be able to delete a single letter in the catalog folder, but they can delete anything inside the letters.

Delete. Everything is simple here. Removal is removal. Doesn't work without Read permission.

Reading permissions Gives the user the right to view permissions on a folder or file. No permission - the user does not see permissions on the Security tab

Change permissions– allows the user to change permissions, essentially making the user the administrator of the folder. Can be used, for example, to delegate authority to technical support. Without the right to read permissions it makes no sense. Changing permissions does not imply changing the owner of the folder.

Change of owner (takeownership)– for starters, who is the owner. The owner is the user who created the file or folder.

The peculiarity of the owner is that he has full access to the created folder, he can give permissions to his creation this folder, but more importantly, no one can deprive the owner of the right to change permissions on his folder or file. If Vasya created a folder, gave Petya full access, and Petya went in and denied user access to the folder in general and Vasya in particular, then Vasya can easily restore the status quo, since he is the owner of the folder. Petya will not be able to change the owner of the folder, even if he has the Change owner permission. Moreover, even Vasya cannot change the owner, despite the fact that he created the folder. The Change Owner right applies only to the Administrators or Domain Administrators group.

But if Petya created a file inside Vasya’s folder and did not give Vasya access to it, then Vasya can only think and wonder what is so secret inside this file. Vasya will not be able to change the access rights to the file, because the owner of the file is Petya. Also, Vasya will not be able to change the owner of the file - changing the owner of subcontainers and objects is also a privilege of the Administrators group, to which Vasya does not belong. The only option left for Vasya is to look at Petya’s file inside his folder.

We manage

CMD uses the well-known icacls to manage permissions. In PowerShell, managing NTFS permissions looks something like this:

Get the object on which we will set permissions
$acl = get-acl c:\testperms
Construct a string with rights using the System.Security.AccessControl.FileSystemAccessRule class. We can set the following parameters:

group/username – for whom we are making the ACL
resolution – ACE (accepts the values specified in the post)
applies to – in the GUI, this is a drop-down list in the advanced security options. In fact, it takes only 3 values: none (only to this folder), containerinherit (applies to all subfolders), objectinherit (applies to all files). Values can be combined.
apply these permissions to objects and containers only inside this container (checkbox in the GUI) - also 3 values: none (the checkbox is cleared), inheritonly (ACE applies only to the selected object type), nopropagateinherit (apply permissions only inside this container).
rule - allow (allow) or deny (deny)

The default permissions line will look like this:
$permission = “contoso.com\admin”,”fullcontrol”,”containerinherit,objectinherit”,”none”,”allow”
Make a new ACE with the permissions defined above
$ace = new-object security.accesscontrol.filesystemaccessrule $permission
And apply the newly created ACE to the object
$acl.setaccessrule($ace) $acl | set-acl c:\testperms

Let's put it into practice

Armed with knowledge of SMB and NTFS permissions, combining them, you can create access rules of absolutely any complexity. Some examples:

Type	SMB permissions	NTFS permissions
Folder for everyone (Public)	Users - Read/Write	Users - Change
Black box. Users send confidential reports, suggestions, slander - the management reads it.	Users - Read/Write Manual - Read/Write	Users - Entry, applies to this folder only. It is assumed that writing a file to this folder is a one-way ticket, since convenient way editing without the right to View the contents of a folder, there are no files saved in this folder (by the way, there is no convenient way for users to write to such a folder). And viewing violates privacy. Leadership - Change.
Applications	Users - Reading	Users – Read, Read and Execute, View Folder Contents. Naturally, some applications may require additional rights to operate. But in general, for example, storage system utilities for diagnostics (the same SysInternals Suite) this is quite enough.
User Profiles	Each user – Read/write to their folder	Each user – Change to his folder.

Permissions in Windows are a controversial thing. On the one hand, the basic resolutions are quite simple and cover 90% of cases. But when more fine-tuning begins to be required: different user groups, one folder, security requirements for shared folders, then it can be quite difficult to deal with additional permissions, inheritance and owners.

I hope I haven't confused anyone more.

Computers running operating systems Windows can work with various file systems such as FAT32 and NTFS. Without going into similarities, we can say one thing that they differ in the main thing - the NTFS file system allows you to configure security settings for each file or folder (directory). Those. For each file or folder, the NTFS file system stores so-called ACLs (Access Control Lists), which list all users and groups that have certain access rights to this file or folder. The FAT32 file system does not have this capability.

In the NTFS file system, each file or folder can have the following security rights:

Reading— Allows browsing folders and viewing a list of files and subfolders, viewing and accessing file contents;
Record— Allows adding files and subfolders, writing data to a file;
Read and Execute— Allows browsing of folders and viewing a list of files and subfolders, allows viewing and access to the contents of a file, as well as launching an executable file;
List of folder contents— Allows browsing of folders and viewing only the list of files and subfolders. This permission does not provide access to the contents of the file!;
Change— Allows viewing the contents and creating files and subfolders, deleting a folder, reading and writing data to a file, deleting a file;
Full access- Allows viewing of content, as well as creating, modifying and deleting files and subfolders, reading and writing data, and modifying and deleting a file

The rights listed above are basic. Basic rights consist of special rights. Specific rights are more detailed rights from which basic rights are formed. Using special rights gives you a lot of flexibility when setting access rights.

List of special access rights to files and folders:

Browse Folders/Execute Files— Allows navigation through the folder structure in search of other files or folders, execution of files;
Folder Contents/Reading Data— Allows viewing the names of files or subfolders contained in a folder, reading data from a file;
Reading attributes— Allows viewing of file or folder attributes such as “Read Only” and “Hidden”;
Reading Additional Attributes— Allows viewing additional attributes of a file or folder;
Creating Files/Writing Data— Allows creating files in a folder (applies only to folders), making changes to a file and writing over existing content (applies only to files);
Creating folders / Adding data— Allows the creation of folders within a folder (applies only to folders), adding data to the end of the file, but not changing, deleting or replacing existing data (applicable only to files);
Recording Attributes— Allows or denies changing file or folder attributes such as “Read Only” and “Hidden”;
Writing Additional Attributes— Allows or prohibits changing additional attributes of a file or folder;
Deleting subfolders and files— Allows deletion of subfolders and files even if there is no “Delete” permission (applies only to folders);
Removal— Allows deletion of a file or folder. If a file or folder does not have Delete permission, the object can still be deleted if the parent folder has Delete Subfolders and Files permission;
Reading Permissions- Allows reading permissions on a file or folder such as “Full Control”, “Read” and “Write”;
Changing permissions— Allows you to change permissions for access to a file or folder, such as “Full Control”, “Read” and “Write”;
Change of owner— Allows you to take ownership of a file or folder;
Synchronization- Allows different threads to wait on files or folders and synchronize them with other threads that may occupy them. This permission only applies to programs running in multithreaded mode with multiple processes;

!!!All basic and special rights are both permissive and prohibitive.

All file and folder permissions are divided into two types: explicit and inherited. The mechanism of inheritance involves the automatic transfer of something from a parent object to a child object. In a file system, this means that any file or folder can inherit its rights from its parent folder. This is a very convenient mechanism that eliminates the need to assign explicit rights to all newly created files and folders. Imagine that you have several thousand files and folders on some disk, how can you distribute access rights to them all, sit down and assign them to each? No. The mechanism of inheritance is at work here. We created a folder in the root of the disk, the folder automatically received exactly the same rights as the root of the disk. Changed the permissions for the newly created folder. Then, inside the created folder, they created another subfolder. This newly created subfolder will have rights inherited from the parent folder, etc. etc.

The result of applying explicit and inherited rights will be the actual rights to a specific folder or file. There are a lot of pitfalls. For example, you have a folder in which you allow the user “Vasya” to delete files. Then you remember that in this folder there is one very important file that Vasya should under no circumstances delete. You set an explicit ban on an important file (special ban right "Delete"). It would seem that the job is done, the file is clearly protected from deletion. And Vasya calmly goes into the folder and deletes this super-protected file. Why? Because Vasya has delete rights from the parent folder, which in this case have priority.

Try not to use assigning rights directly to files; assign rights to folders.

!!! Try to assign rights only to groups, this greatly simplifies administration. Assigning rights to specific users is not recommended by Microsoft. Don't forget that a group can include not only users, but also other groups.

For example. If the computer is included in a domain, then the “Domain Users” group is automatically added to its local “Users” group, and the “Domain Admins” group is automatically added to the local “Administrators” group, and accordingly, assigning any folder rights to a group of local users, you automatically assign rights to all domain users.

Don’t be discouraged if everything described above is not immediately clear. Examples and independent work will quickly correct the situation!

Let's get down to specifics.

I will show all examples by example Windows windows XP. In Windows 7 and higher, the essence remained identical, only there were slightly more windows.

So, to assign or change rights to a file or pack, you need to right-click on required file or folder select menu item "Properties"

A window with a bookmark should open. "Safety"

If there is no such bookmark, then do the following. Launch Explorer, then open the menu "Service"—"Folder properties..."

In the window that opens, go to the “View” tab and uncheck the option "Use simple file sharing (recommended)"

That's it, now all the properties of the NTFS file system are available to you.

Returning to the bookmark "Safety".

In the window that opens, a lot of information is available to us. There is a list at the top "Groups and users:", which lists all users and groups that have access rights to this folder (arrow 1). The lower list shows permissions for the selected user/group (arrow 2). In this case it is the user SYSTEM. This list of permissions shows the basic permissions. Please note that in the column "Allow" checkmarks are faded in color and cannot be edited. This indicates that these rights are inherited from the parent folder. Once again, in this case, all rights of the SYSTEM user to the folder "Working" are completely inherited from the parent folder, and the SYSTEM user has all rights ( "Full access")

Highlighting in the list the desired group or user, we can look at the basic rights for that group or user. By selecting the user "Guest user ( [email protected])» you can see that he has all rights explicit

And here is the group "Users (KAV-VM1\Users" has combined rights, some of them are inherited from the parent folder (gray squares opposite "Read and Execute", "List the contents of the folder", "Reading"), and part of it is established explicitly - this is the right "Change" And "Record"

!!!Attention. Pay attention to the names of users and groups. Group or user affiliation is indicated in brackets. Groups and users can be local, i.e. created directly on this computer, or can be domain. In this case the group "Administrators" local, since the entry in brackets indicates the name of the computer KAV-VM1, and after the slash there is the name of the group itself. On the contrary, the user "Guest user" is a user of the btw.by domain, this is indicated by the full name record [email protected]

Often, when viewing or changing rights, you can limit yourself to a window with basic rights, but sometimes this is not enough. You can then open a window where you can change specific permissions, change the owner, or view current permissions. How to do this? Click on the button "Additionally". This window opens

In this window in the table "Permission Elements" All users who have rights to this folder are listed. In the same way as for basic permissions, we highlight the desired user or group and click the button "Change". A window opens showing all special permissions for the selected user or group

Similar to basic permissions, special permissions inherited from a parent folder will appear faded gray and will not be editable.

As you may have already noticed, there are several lines in the special permissions window for some users or groups.

This happens because one user or group can have different types of rights: explicit and inherited, allowing or denying, differing in the type of inheritance. In this case, read rights for the Users group are inherited from the parent folder, and edit rights are added explicitly.

Examples of assigning rights.

!!! All examples will progress with increasing complexity. Read and understand them in the same order as they appear in the text. I will omit similar actions in subsequent examples to reduce the volume of text. 🙂

Example 1: Granting read-only access to a folder to a specific local security group.

First, let's create a local group, which will include the entire list of users we need. It is possible without a group, but then for each user you will need to configure rights separately, and every time you need to give rights to a new person, you will need to do all the operations again. And if you grant rights to a local group, then setting up a new person will require only one action - including this person in the local group. How to create a local security group can be found in the article “Configuring local security groups”.

So. We have created a local security group called "Colleagues for Reading"

to which we added all the necessary users.

Now I’m setting up access rights to the folder. In this example, I will give access rights to the created group "For colleagues to read" to folder "Photo".

Right-click on the folder "PHOTO" and select a menu item "Properties", go to bookmark "Safety".

In the opened bookmark "Safety" current folder permissions are displayed "PHOTO". By selecting groups and users in the list, you can see that the rights of this folder are inherited from the parent folder (gray checkmarks in the column "Allow"). In this situation, I don't want anyone other than the newly created group to have any access to the folder "PHOTO".

Therefore, I must remove rights inheritance and remove unnecessary users and groups from the list. I press the button "Additionally". In the window that opens,

I uncheck the box “Inherit permissions applicable to child objects from the parent object, adding them to those explicitly specified in this window.” . This will open a window in which I can choose what to do with the current inherited rights.

In most cases I recommend clicking the button here "Copy", because if you choose "Delete", then the list of rights becomes empty, and you can actually take away the rights from yourself. Yes, don't be surprised, it's very easy to do. And if you are not an administrator on your computer, or not a group user "Archive Operators", then it will be impossible for you to restore your rights. The situation is similar to a door with an automatic latch that you close while leaving the keys inside. So it's better to always press the button "Copy", and then delete what is unnecessary.

After I clicked "Copy", I return to the previous window again, only this time with the checkbox unchecked.

I press "OK" and return to the basic rights window. All rights have become available for editing. I need to leave permissions for the local group "Administrators" and user SYSTEM, and delete the rest. I select unnecessary users and groups one by one and click the button "Delete".

As a result, I get this picture.

Now all I have to do is add the group "For colleagues to read" and assign read permissions to this group.

I press the button "Add", and in the standard selection window I select the local group "For colleagues to read". How to work with the selection window is described in detail in the article.

As a result of all the actions, I added the “Colleagues for reading” group to the list of basic rights, and the rights for this group were automatically set "Read and Execute", "List the contents of the folder", "Reading".

All you have to do is press the button "OK" and rights are assigned. Now any user who belongs to the local security group "Reading for colleagues" will be able to read the entire contents of the folder "PHOTO".

Example 2: Giving users personal access to their subfolders in a folder.

This situation is also common in practice. For example, let's say you have a folder for new scanned documents. In this folder, each user has his own separate subfolder. After scanning, the document is taken by the user from its subfolder. The task is to assign rights so that each user sees the contents of only his own subfolder and cannot access a colleague’s subfolder.

For this example, I will rephrase the task a little. Let's assume we have a shared folder "PHOTO", in which there is a subfolder for each user. It is necessary to configure the rights so that the user has all rights in his subfolder, and the subfolders of other users are inaccessible to him.

For this setup, I completely repeat all the steps from the first example. As a result of repetition, I get rights for the entire group "For colleagues to read" to read to all subfolders. But my task is to make only “my” subfolder visible to the user. Therefore, in the basic rights window I click the button "Additionally"

and go to the special rights window, in which I select the group "For colleagues to read" and press the button "Change"

In the window that opens, I change the inheritance rules, instead of the value in the field "Apply:" I choose the value "Only for this folder".

This is the most key point of this example. Meaning "Only for this folder" causes read permissions for the group "For colleagues to read" apply only to the root of the folder "PHOTO", but not to subfolders. Thus, each user will be able to get to his own folder, but will not be able to look into the neighboring one; he does not have the right to view subfolders. If you do not give this right to the group at all, then users will not be able to get into their subfolders at all. The file system will not allow them even into the folder "PHOTO".

As a result, users will be able to access the folder "PHOTO" but they won’t be able to go further into the subfolders!

In the special rights window, click "OK" and go to the previous window, now in the column "Apply to" opposite the group "For colleagues to read" worth the value "Only for this folder".

Click in all windows "OK" and we go out.

All. Now all that remains is to configure personal rights for each subfolder. This will have to be done for each subfolder; the rights are personal for each user.

You have already done all the necessary actions in the first example, let’s repeat what we have covered :)

On a subfolder "User1" I right-click the mouse and select the menu item "Properties", go to bookmark "Safety". I press the button "Add"

and in the standard selection window I select a domain user with the name "User1".

All that remains is to check the box for the permission right "Change". In this case, the checkbox for the allowing right "Record" will install automatically.

Click "OK". Let's go out. It remains to repeat similar steps for all subfolders.

Example 3. Providing personal write access to a user’s subfolder, while simultaneously prohibiting modification or deletion.

I understand that it sounds difficult, but I will try to explain. I call this type of access a latch. In everyday life we have a similar situation with ordinary by mailbox, into which we throw paper letters. Those. You can throw a letter into a box, but you can’t take it out of the box. In computer science, this can be useful in a situation where someone writes a report to you in a folder. Those. the file is written by the user, but then this user can no longer do anything with this file. This way, you can be sure that the creator will no longer be able to change or delete the submitted report.

As in the previous example, we repeat all the steps, except that we do not immediately give the user full rights to his folder, initially in basic permissions we only give read access, and click the button "Additionally"

In the window that opens, select "User1" and press the button "Change"

In the window that opens we see standard read permissions

In order to give the user the right to create files, set the permission to the right “Creating Files/Writing Data”, and on the right "Deleting subfolders and files" And "Delete" we put a ban. We leave inheritance as standard "For this folder, its subfolders and files".

After pressing the button "OK" and returning to the previous window, you can see significant changes. Instead of one entry for "User1" two appeared.

This is because two types of rights are established, one prohibiting, they are first in the list, the other is permissive, they are second in the list. Since special rights are non-standard, in the column "Permission" worth the value "Special". When the button is pressed "OK" A window appears to which Windows warns that there are prohibiting rights and that they have higher priority. Translated, this means the same situation with a self-closing door, the keys to which are located inside. I described a similar situation in the second example.

All. Rights have been set. Now "User1" will be able to write any file to its folder, open it, but will not be able to change or delete it.

But what about the complete analogy with a real mailbox?

To prevent the user from opening or copying the recorded file, you need to do the following. Again we open allowing special permissions for "User1", and in the field "Apply:" change the value to "Only for this folder"

In this case, the user does not have the right to read or copy the file.

All. Now the analogy with a physical mailbox is almost complete. He will only be able to see the names of the files, their size, attributes, but he will not be able to see the file itself.

View current rights.

I want to say right away that the ability to view the current rights for a folder or file is a complete fiction. In my opinion, such tools should provide guaranteed information. This is not the case here. Microsoft itself admits that this tool does not take into account many factors that influence the resulting rights, such as entry conditions. Therefore, using such a tool is only deceiving yourself regarding real rights.

The case described at the very beginning of the article, with the ban on deleting a file from a folder, in this case is very eloquent. If you simulate similar situation and look at the rights of the file protected from deletion, you will see that the file’s permissions to delete are prohibited. However, deleting this file is not difficult. Why Microsoft did this, I don't know.

If you still decide to look at the current rights, then in the basic rights window you need to click the button "Additionally", and in the special rights window go to the tab "Valid Permits".

Then you need to press the button "Choose" and in the standard selection window select the desired user or group.

Once selected, you can see “approximate” valid permissions.

In conclusion, I want to say that the topic of NTFS file system rights is very extensive; the above examples are only a very small part of what can be done. Therefore, if you have any questions, ask them in the comments to this article. I'll try to answer them.