File it!

Setting up DFS at home? Learn from Charlie.

2004-04-27T00:11:00Z

It always amazes me when I learn the advanced home networks some people set up. Charlie Kindel has set up DFS in his home, and wrote a nice entry in his blog about some of the troubleshooting he had to do. If you're having problems accessing a domain DFS namespace, check out Charlie's entry. The problem may simply be that the DFS service is turned off on one of your domain controllers.

http://kindel.com/blogs/charlie/posts/259.aspx

Understanding the policy "Do not automatically make redirected folders available offline"

2004-02-06T21:00:00Z

Today, the CSC team (the people who bring you Offline Files in Windows 2000 and Windows XP) was helping a customer understand the ramifications of the policy "Do not automatically make redirected folders available offline." If you're in a situation where you've made a special folder available offline -- a folder such as My Documents -- and not all of the files you expect to see are available when offline, it's worth checking this policy setting.

In Windows 2000, when a special shell folder (such as My Documents) is redirected by the Folder Redirection feature (as opposed to directly modifying registry keys), Folder Redirection pins the top-level directory entry and its desktop.ini file if one is applicable. No other files or folders are pinned by that operation. The objective of this minimal operation was to keep the Windows shell operational when the redirected resource becomes unavailable. The goal was not to provide offline access to the redirected content. In order for files or subdirectories to be available offline, the contents of the root directory of the redirected folder (and optionally all of its subfolders) must be pinned either manually by the user or administratively through Group Policy. Once the root directory of the folder is pinned in this way, Offline Files now considers the redirected folder to be "pinned" and the normal semantics of a pinned folder are realized.

We received feedback from several large Windows 2000 customers that their expectation differed from the as-designed behavior. These customers expected that the redirection of a shell folder implies the offline availability of that folder and all of its content. They did not want to take the additional steps of pinning the redirected folder manually or through Group Policy. As a result, the default behavior in Windows XP was changed so that Offline Files automatically pins the contents of a redirected shell folder (again, when redirected by the Folder Redirection feature).

It is important to note that the act of redirecting the folder still does not pin the content. Redirection pins only the folder root directory and its desktop.ini file if applicable. This is so that the process of redirection can complete relatively quickly. Offline Files then later pins the contents in the following situations:

During a logoff synchronization, we always scan the contents of redirected shell folders pinning files not already pinned, regardless of the "sync all files before logging off" setting. There is one exception. We do not do this operation if the associated network path is considered "slow".
The code that processes the "Administratively assigned offline folders" policy also pins the unpinned contents of redirected shell folders. This behavior was added to address the scenario where users tend to not log off.

There are several reasons why a customer may not want to use this new default behavior.

It is relatively expensive.
To retain consistency with Win2000 clients

Anticipating that some customers might not want this default behavior, we introduced the "Do not automatically make redirected folders available offline" policy. With this policy enabled, the behavior is equivalent to Windows 2000 as described earlier.

Understanding ACLs in NTFS

2004-01-21T04:04:00Z

Associating Access Control Lists (ACLs) with files is the fundamental mechanism for securing file system data. Consequently, the #1 rule for securely storing data in files is to ensure the proper ACLs are on your files.

Using NTFS so you can have ACLs is not enough. You need to know what ACLs you want to put on your files, and you need to know how to go about putting ACLs on your files so you can avoid common mistakes. For determining what ACLs to put on files, refer to Writing Secure Code, pages 95 – 98. This post will deal with how you go about ensuring the ACLs you want are actually on the files you want. There are several common misconceptions about ACLs in the file system that can lead to security holes. However, if you obey the following rules, you should be able to properly ACL your data.

1. Rely only on the ACL on the file to provide security

This rule seems so obvious that nobody could get it wrong: if you want to secure access to a file, you put an ACL on that file. However, there are several well-intentioned ways to violate this rule. Consider the following:

· "I don't need a strong ACL on my file, because I (put the file in a hidden location / put the file in a directory with a strong ACL)."

Hopefully, anybody trained to think of security threats will realize that the obscurity of a file's location is no protection. This is particularly true on NTFS, which provides a change journal that tells applications what files on the disk have been changing. You may think that nobody knows where you are creating your log file, but NTFS will happily tell people who ask.

It is also not sufficient to rely upon the ACL on a directory to protect the contents of a file — there are three ways that an attacker can bypass directory security and access a file. First, if the attacker knows or can guess the name of the file, he can just open the file. By default, Windows does not check if a user has permissions on parent directories when opening a file. Second, if the attacker knows the file ID, he can open the file by ID. Finally, the attacker can do the same thing with the object ID for the file.

· "I don't need a strong ACL on my file, because I open an exclusive-access handle to the file."

When you create a file handle using CreateFile( ), you get to specify a sharing mode. This tells the operating system to place constraints on the types of handles that may be opened concurrently with yours. For example, you may choose not to share access with other read handles.

However, the sharing mode is a coarse-grained mechanism for concurrency control; it is not a mechanism to secure access to data. Using sharing modes for security has three problems. First, the proliferation of shadow copy technology within Windows means that, while you may be able to use sharing modes to keep people from reading the current version of a file, there is a high likelihood that there is a read-only copy of the file that is unprotected by sharing modes. Second, there is an inherent race condition when you try to use sharing modes for security: what if the attacker is able to open his handle before you? Finally, if you ever close your handle — for example, if your application AVs — then the data is unprotected.

In short, if you want to secure access to a file, the only reliable way is to place an appropriate ACL directly on the file.

2. Understand how ACL inheritance works

Once you know the ACL that you want to put on your file, and you know to put the ACL on the file and not some other directory, you need to understand how you are applying the ACL to your file. One mechanism for putting an ACL on a file is to use object inheritance. In this scenario, you place your desired ACL on the directory you store your files in, and then mark the directory to have child objects inherit the ACL.

There is nothing wrong with using directory inheritance as the mechanism for applying ACLs to your files. This is probably the most convenient way to apply ACLs to files if your application stores all of its files in a single directory. However, the common misunderstanding of inheritance is that the ACLs automatically apply to any file in the directory. This is not true: the ACLs are inherited only for new files created in that directory. If you move an existing file into the directory, it will retain its ACLs. Therefore, you cannot rely upon ACL inheritance to secure access to files that you move into secured directories.

3. Understand the risks of Delete child access right

For the most part, you rely only on the ACLs on files to secure access to files. However, there is a vulnerability for files that relates not to a weak ACL on the file, but rather to the ACL on the file's directory. If an attacker has Delete child access right for a directory, then he has the ability to delete any file in that directory — even files that he has no access to.

The ability to delete a file is particularly dangerous if it is coupled with the ability to read the file and create new files in the directory; the combination of these privileges is equivalent to Take ownership. Why? Because the attacker can read the data from the file, delete the file, and then recreate a file with the same name and with the same data — only now the attacker is the owner, with implicit full control over the data, and you might not ever realize it.

In summary, the best practices for securing access to a file comes down to:

· Use the ACL on the file, not on directories, to control who gets to access the file.

· Carefully guard who has Delete child access right on directories.

What's the "Web Client Network"?

2004-01-20T01:49:00Z

I had a customer ask me this today, so in case others are wondering: What's the “Web Client Network”?

If you open Windows Explorer, click Network Neighborhood, then click Entire Network, you'll see an icon for Web Client Network. The customer saw nothing under this icon, so was wondering why it was there in the UI.

The short answer is that icon is present to display any WebDAV connections that your machine has. As many machines don't make WebDAV connections, that's why there was nothing under the icon for this particular customer.

The long answer: Windows clients can access files on other machines using a variety of network protocols. Each installed network protocol that the client supports gets an icon under Entire Network in My Network Places. The native protocol that Windows clients and Windows servers support is known as SMB. (A version of the SMB protocol was publicly licensed and is called CIFS.) If you expand Microsoft Windows Network under Entire Network, you will see computers that you can connect to using the SMB protocol.

Starting with Windows XP, Windows clients can also connect to machines using the WebDAV protocol. This is a file sharing protocol supported by some web servers, such as http://www.msnusers.com. If you have any active WebDAV connections, you will see them listed in Web Client Network.

What makes a valid Windows file name?

2004-01-19T22:02:00Z

A common question for people starting to program on Windows is, “What makes a valid Windows file name?” You want to use this information to make simplifying assumptions in your code: that names can be no longer than MAX_PATH, that two names won't differ only by case, etc. Unfortunately, the answer to what makes a valid file name in Windows is not simple.

Due to the layering of Windows architecture, the definition of a "legal" file name may vary depending upon the component of the operating system you are dealing with.

· NTFS and the Posix subsystem have the most permissive definition of a "legal" name. The name may be up to 32,768 Unicode characters long. The name can contain trailing periods, trailing spaces, and two files may have names that differ only in case (e.g., README.TXT and readme.txt).

· The Win32 subsystem enforces additional constraints on legal file names. The name can be at most MAX_PATH characters long (defined in windef.h as 260 characters), may not have trailing dots or spaces, and file names are case preserving, not case sensitive — if two files exists with names that differ only in case, you will only be able to manipulate one of them through Win32 APIs.

· DOS and 16-bit Windows applications are still limited to "8.3" names.

See Inside Windows 2000, pages 729ff, for more information on the different constraints on file names.

These differences have practical consequences for any code that attempts to manage files that could be created by another program. If your management code uses DOS (heaven forbid!) or Win32 APIs to manipulate files, it is possible for the untrusted program to create files that your program cannot open or manipulate. For example, a user connected to Posix-based FTP server could create files with file names longer than MAX_PATH. If the administrator uses a Win32-based program to manage the FTP upload directory, then he will not be able to open, delete, or otherwise manipulate the files with long file names.

If you are writing a Win32-based program that manages arbitrary files, consider prepending "\\?\" to the start of file names before you call CreateFile( ), DeleteFile( ), RenameFile( ), etc. This escape sequence at the start of a file name instructs the Win32 subsystem to bypass its normal name checking functions, and you will be able to use any valid NTFS name from your Win32 program.

Welcome

2004-01-19T21:57:00Z

Hello. I'm the Lead Program Manager for network file system technologies in Windows. As I've watched the adoption of blogs as a way to share information among the development community, I thought it would be a good idea to provide a place to share tips and tricks about interacting with the file system in Windows. Thus, this blog was born. I'll use this space to share information on interacting with file systems, network file systems, our built-in file replication engine, etc. Let me know what you want to hear about, and I'll do my best to provide that information!

--Brian