Windows file write permissions

With such naive administrators, directories that have user write must not allow administrator execute privileges in order to prevent a user from installing an executable and then fooling an administrative user into running it and compromising the system. For example, if your application or service needs to store log information that will be written to under user privileges, you should create a logging subdirectory to hold this data.

This subdirectory should not allow admin execute. This prevents cross-user attacks in directories that allow file write or modify to users. There are many cases where it is expected that users will share data though we do not want users sharing and executing code from a shared area.

The user expects to be able to allow multiple users to write to this folder and have multiple users edit the various photos in this folder. The other common sharing situation is a folder in which users place data for other users to read.

Only the creator of the data is allowed to delete or modify the data, but other users may copy it and then edit the copy. This is a shared read scenario, and it is the default for the system drive on Windows Server Consider the case where you choose to lock down the system drive and, specifically, ACL folders for sharing.

You have to choose the ACLs that are appropriate for these two rather common scenarios. We want administrators to be able to manage the objects and we want to prevent security issues associated with execution of code in these folders note that the ACEs here prevent even the owner from executing code from these folders.

Note that both ACLs start with a deny execute ACE for everybody, object inherit to apply it to files , to prevent user system and cross-user attacks. For the Collaborative scenario, an authenticated user is granted Delete, Generic Read, and Generic Write on files and directories.

Windows stores much of its state information in the Windows Registry. Registry data stores are known as Hives, where data is stored in keys and subkeys, which are both viewed as containers subkeys are not viewed as objects.

As one would expect, much of this data is writeable by the user. Included in HKLM is information for all the various system services, most of which now run with limited permissions under either the various Local Service or Network Service groups.

Services and applications can store state information in their registry keys. This information should be stored in subkeys, either in the service key or in a key under the service key.

The service key must not be ACL'd to enable the service to have SetKey over its own service key or the WDac or WOwn, which would enable such an attack , as this allows the service to point to a different executable.

Such an error introduces a potential EoP against the service host, as the Service Control Manager will load the executable that is pointed to when the system loads. As with the guidance on setting file system DACLs in system areas, exceptions occur for error logging where an app or a service running under a user or limited context needs to record error information. The guidance for such situations is similar to equivalent issues in the file system—create separate keys for such information and ACL them appropriately.

Thus the sensitive information can be ACL'd to trusted subjects administrator, system, and so on and the logging data can be writeable, as needed. The situation you are trying to avoid is a user modifying trusted parameters such as turning the antivirus or anti-malware service off or tampering with a tool that users or administrators use.

This could load a rootkit and then load Notepad so that the user would not be aware of the compromise. If the attacker can drive the link through the registry, the protective ACLs on the file system are immaterial.

You are concerned with attacks from limited system services against other system services as well. In Windows Vista and Windows Server , services are separated into groups by the privileges they need.

The defense-in-depth protections offered by this service isolation require configuration of the service permissions so that services cannot tamper with one another, particularly across service groups. Just as we are concerned with preventing users from adding or linking to malicious executables, we must also prevent services from having the ability to change their permissions and capabilities.

The ChangeConf privilege on services must be restricted to administrator, system, or Trusted Installer since this privilege allows the possessor to change the permissions on the service.

Windows provides a very rich set of permission controls that can be used to permit operations, block operations, and provide defense-in-depth against new threats. Unavoidably associated with this rich ability to control access is the issue of complexity. Following a few general guidelines will help you avoid problems. For instance, the system defaults are reasonable compromises. You should use them.

If you are installing an application outside of program files, use the program files ACLs. In some cases you may want to tighten defaults a little bit, such as the default grants to users on drives; but remember that if you indeed do this, you must be prepared to look for and deal with potential application compatibility issues.

The most important guideline is that administrators or system accounts must not execute code or follow pointers to code that a user can write or modify. Almost as important is that users not execute code or follow pointers to code that another user can write or modify. These guidelines drive all of the security issues discussed here.

If any changes you make follow these guidelines, you have avoided the most serious security issues. John R. Michener is senior security program manager for Microsoft.

He joined Windows Security at Microsoft almost 5 years ago. John has more than 20 years of experience in system security and has done three security startups. He is the cryptography and permissions expert for the Windows Software Assurance team. You can reach him at jmichene microsoft. Skip to main content.

This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. In this article. Remember, folder permissions can only be changed by the owner of the folder i. If you are not the owner of the folder or have not been granted permission by the owner, the checkboxes will be grayed out.

Was this article helpful? Yes No. The following table represents the available standard permission types. Permission Description Full Control Permits the user s to: view file name and subfolders. Modify Permits the user s to: view the file names and subfolders. List Folder Contents Permits the user s to: view the file names and subfolder names.

Read Permits the user s to: view the file names and subfolder names. Write The Read permissions, plus permits the user s to: create folders. Create a New Folder In many cases you will need to create a new folder. Click on the Start menu. Click Computer. Navigate to the location you want the new folder to appear e. On the menu bar, select New Folder. OR Right click » select New » select Folder. A new folder is created which inherits the security permissions of its "parent.

Press [Enter] or click off of the folder. Accessing the Properties Dialog Box When working with permissions in Windows 7, you are required to work from the Properties dialog box. Right-click the folder or file. Select Properties. The Properties dialog box appears. Granting Access to a File or Folder After creating a new folder, or even if you will use an existing folder, you will need to determine who will have access to it.

Access the Properties dialog box. Select the Security tab. Click Edit. Of course, there are other alternatives like hiding files and folders using file attributes or by using the command prompt to hide data. You can even hide an entire drive in Windows if you like. If you are looking to set permissions in order to share files with others, check out my post on creating a hidden network share or how to share files across computers, tablets and phones.

The only other occasion where you will need to mess around with folder or file permissions is when you get a Permission Denied error when trying to access data. This is important because it means that setting permissions on a file or folder does not guarantee the security of that file or folder.

In Windows, an administrator on any Windows PC can override the permissions on a set of files and folders by taking ownership of them. Once you have ownership, you can set your own permissions. So what does this mean in English? The only version you should download is TrueCrypt 7. If you are not comfortable at all using TrueCrypt, the only other suggestion I have is VeraCrypt , which was the successor to TrueCrypt, but fixed many of the flaws. Every file and every folder in Windows has its own set of permissions.

Permissions can be broken down into Access Control Lists with users and their corresponding rights. Here is an example with the user list at the top and the rights at the bottom:. Permissions are also either inherited or not.

Normally in Windows, every file or folder gets their permissions from the parent folder. This hierarchy keeps going all the way up to the root of the hard drive. You can access these permissions by right-clicking on a file or folder, choosing Properties and then clicking on the Security tab.

To edit permissions for a particular user, click on that user and then click the Edit button. Note that if the permissions are greyed out, like in the example above, the permissions are being inherited from the containing folder.

List Folder Contents is the only permission that is exclusive to folders. So what do each of these permissions mean? Before you can edit any permissions, you have to have ownership of the file or folder. Read my previous post on how to take ownership of files and folders in Windows if you are currently not the owner. If you right-click on a file or folder, choose Properties and click on the Security tab, we can now try to edit some permissions.