Problems with Permissions

The Server service has been part of Windows NT–based OSs since day one, and the vast majority of Windows servers are file servers. You’d think that we IT professionals and Microsoft would have this file-server thing ironed out by now. Unfortunately, that’s not the case. I’ve heard from countless business clients (and these aren’t momand- pop shops) that IT still isn’t configuring file servers right. And Microsoft isn’t helping. In fact, in some cases Microsoft is adding to the problems in its newest OS versions by creating what I call “tools for dummies,” such as the new Windows Server 2008 Share command, which isn’t customizable and applies really poor default configurations. Although file servers are one of the most common causes of annoyance for IT, the situation isn’t hopeless. You can align file server technologies with business requirements, and I’ll show how you can work around the problems with permissions, such as Full Control or Modify, and some of their defaults, such as the default inheritance of the delete permission, that Microsoft wants you to use.

Full Control or Modify Most of us know the dangers of Full Control. Fewer of us have considered scenarios in which Modify is a risky permission to apply. I can write pages on the dangers of assigning Modify and Full Control permissions to groups, but I’ll narrow down my scope here to one of the most severe problems these permissions can cause: granting Delete permission.

In most collaborative file-sharing scenarios, such as sharing a team folder, a group of information workers receives Modify or Full Control permission. The danger is that Modify and Full Control permissions templates include the Delete permission, which applies by default to “this folder, subfolders, and files.” With this permission and its inheritance, a user in the group can delete any and all files and subfolders. In other words, anyone on the team can select a folder and press the Delete key. Say au revoir to your data and hello to denial of service. Such a deletion could be malicious or accidental, but it can be prevented.

Spend some time defining the requirements of your collaborative shared folders, and be aware that permissions used for good can also be used for evil. You’ll find that, depending on the requirements of the particular folder you’re granting permissions for, you can solve the Delete problem in a number of ways. First, you can give the whole group Allow::Write permission, which lets anyone in the group create and change files and folders. Then, give a more restricted group the Delete permission. Second, you can grant the group Modify permission but change the scope of the permission to apply to Files only. This still allows an accidental or intentional deletion of files within the folder, but it stops the recursive deletion of subfolders in the event of an accidental deletion.

Delete Subfolders and Files Even more perilous is the Delete Subfolders and Files permission, an access control entry (ACE) in the Full Controls permission template. A user with this permission on a folder can delete any subfolder or file within the folder, even if the user has explicit Deny:: Delete permission. So, any user who’s a member of a group with Full Control of a folder can delete all of its contents, creating a denial of service situation. This is far worse than the standard Delete permission because Delete Subfolders and Files overrides all other permissions, including explicit Deny permissions. It’s a doozy in the wrong hands.

To avoid this problem use Best Practice Number Two: Be extremely careful about granting Full Control. I recommend restricting Full Control to System. Give the Modify permissions template plus Change Permissions permission to support groups who need to change folder permissions.

By the way, Best Practice Number One is: Always assign permissions to groups, not users. This point leads me to the next annoyance.

Creator Owner ACE Most organizations have increased their focus on security policy, which makes defining rules for access essential. For shared folders, the parent folder ACL determines the access policy. A team shared folder, for example, is typically set to allow team members to read each other’s files. Often they can add files to the share, and sometimes they can even change each other’s files. The problem is that on each new folder, there’s a default ACE that gives the Allow::Full Control (Apply To Subfolders and Files) permission to the special identity Creator Owner. When a user creates a file or folder, the ACE assigned to Creator Owner is applied to that specific user.

So, for example, if Dan Holme joins the team and creates a new file in the team share, he receives Allow::Full Control permissions for that file. What if Dan leaves the team? He’s removed from the group that can read and create files in the share. But he can still access his file because he has an explicit Allow::Full Control ACE on that file. So just because Dan created the file, he’s exempt from the entire shared folder’s access policy, which specifies that only team members have access. Even if an administrator uses the Change Owner function to assign the file to another team member, Amy, Dan still has his explicit permission (and Amy does not inherit Dan’s Full Control permission) unless the administrator changes the file’s permissions.

To fix this annoyance, analyze the capabilities needed by the shared folder users. You might decide to remove the Creator Owner ACE. If you’ve assigned team members the Allow::Write permissions template so they can change each other’s files on the share, you don’t need the Creator Owner ACE. Without this ACE, when Dan joins the team and creates a file, the new file inherits the access policy of the parent folder but doesn’t add an explicit ACE for Dan. He can modify his file because he’s on the team, but when he leaves the team, his access is removed. There’s one more catch: Dan can, as owner, return to the object and give himself permissions. We’ll solve that one next.

Changing Permissions Every organization has battled problems caused by users maliciously or inadvertently changing permissions on files or folders they’ve created. Windows provides an implicit permission (WRITE_DAC) to the security identifier (SID) of the user who owns a file or folder. WRITE_DAC enables the user to change permissions on the object, even if he or she wouldn’t otherwise have Allow::Change Permissions. This ability represents a significant security problem because the owner of a file or folder can change the access policy defined by the ACL on the parent folder.

Prior to Windows Vista, the only viable solution was to change the Server Message Block (SMB) permissions (i.e., share permissions). Most administrators use Allow::Full Control as the SMB permission. But if you change it to Allow::Change, the more restrictive SMB permission will allow every action except changing permissions.

Vista and Windows Server 2008 make it even easier to solve the problem by adding a new special identity, OWNER RIGHTS, which represents the current owner of a file or folder. Permissions assigned to this identity will set the permissions for the owner, overriding the owner’s implicit rights, including the right to change permissions. So the new best practice is to assign OWNER RIGHTS::Allow::Modify. The Modify permission doesn’t include the Change Permissions, Delete Subfolders and Files, and Take Ownership permissions included in the Full Control permissions template. As soon as your file servers are running Server 2008, this annoyance will be history.

Users See but Can’t Access When users open folders, they can see all of the contents, by default, including files and folders to which they don’t have access. I don’t have a problem with such visibility: As long as the file or folder can’t be opened, visibility doesn’t really matter. However, if it matters to you, here is my guidance: Reorganize your files and folders or implement Access-Based Enumeration, which is available for Windows Server 2003 from Microsoft’s downloads site at microsoft.com/downloads/details.aspx?FamilyID=04A563D9-78D9-4342-A485-B030AC442084&displaylang=en. (For more details, see the Windows IT Pro “File and Print Annoyances” article, February 2007, Instant- Doc ID 94675.)

Continued on Page 2

   Previous  [1]  2  Next