Tools to Manage Access Control Lists

In addition to the updates to ACLs mentioned previously, Microsoft has also updated some of the tools you use to manage ACLs. Interestingly, the most significant of these updates are command-line tools.

Cacls and Icacls

Most people are familiar with the venerable cacls tool that has been in every version of Windows NT since it first came out. If you run cacls.exe in Windows Vista you are greeted with this message:

      Microsoft Windows [Version 6.0.5744]      Copyright (c) 2006 Microsoft Corporation.  All rights reserved.      C:\Windows\system32>cacls        NOTE: Cacls is now deprecated, please use Icacls. 

A new tool, called icacls, will eventually completely replace cacls. Cacls, as you may be aware, was never completely updated to support the more granular permissions introduced with Windows 2000, making this an update that is about seven years overdue.

In spite of it being deprecated, cacls does actually include some new features. First, it is aware of both junction points and symbolic links, and knows to traverse those now. Second, it can both print and set an ACL using an SDDL string, which it was never capable of doing.

In spite of the updates to cacls, it is icacls you want. Icacls has some very useful functionality that you are sure to appreciate

Save ACLs

A constant wish for the past 10 years has been the ability to save an ACL so that you can restore it at a later date. This turns out to be one of the most complicated operations you can perform on ACLs. Except in certain special cases, it is unlikely that you get back to exactly where you would have been had you not ruined the ACLs in the first place. For some elaboration on the difficulties of saving and restoring ACLs, see the sidebar "Saving/Restoring ACLs." Nevertheless, it can be quite useful.

To save an ACL you run icacls with the /save switch:

      icacls <directory or object> /save c:\acls.bin /t 

This would save the ACLs to a file called acls.bin. The file will contain one line for each object with an ACL followed by one line specifying the ACL in SDDL. If you use the /t switch, the command will operate on the object you specified and all objects and containers underneath it.

The save functionality is a welcome addition to the toolkit, but it is lacking in several respects. First, it saves only the DACL, not the SACL. In fact, if there is a SACL, it saves a dummy value that indicates this, but it does not actually save any part of the SACL.

SAVING/RESTORING ACLS

Say you have a hierarchy containing user data for students at a local college. You save the ACL on February 1. On April 17 you discover that somehow the ACL has been corrupted and you go to restore it from the saved copy. What complications could there be with this operation? First, the new quarter started on April 2. About 15 percent of your students graduated and are no longer with you; consequently, their directories no longer exist. Thus, you have ACLs in the backup file that are invalid. You also have a batch of new students, another 15 percent that started with the new quarter. They have home directories now, but no ACLs in the backup file. What should their ACLs be? Then, of course, you have the 70 percent that are still there, but they have created new files and folders, and deleted others. You can ignore the deleted ones, but how do you configure the new folders they created? What if a student decided to share a folder with his friends on March 4? Will you break that? Clearly, saving and restoring ACLs is not nearly as simple an operation as many people would have you believe.

Restore ACLs

Once you have saved an ACL using the /save switch you can restore it using the /restore switch. Before you go any further, however, you probably want to read the sidebar with the warning about editing saved ACLs.

WARNING: DO NOT EDIT YOUR SAVED ACL

If you were to open the file containing your saved ACL in a text editor you would find that it appears to be a Unicode formatted text file. In fact, that is almost exactly what it is. This might lead people to edit it, or save it from the text editor. If you open the file with the saved ACLs in a text editor and save it you will not be able to restore the ACLs from it. It is not actually a Unicode formatted text file after all. Such a file must begin with the two bytes 0xfffe. If you save the file with a text editor, such as Notepad, it will in fact put that flag into the file in the first two bytes. The icacls tool will then be unable to parse the ACLs in the file as it expects the first two bytes to be part of the string specifying the object to operate on. Your backup file will be unusable.

Microsoft is aware of this problem, but as it was only reported very late in the beta cycle for Windows Vista, it was not fixed prior to release. At this point we do not know when, or even whether, it will be fixed so for now, the best advice is to not edit your saved ACLs.

The restore command in its simplest form looks like follows:

 icacls <directory> /restore acls.bin 

The restore command does not operate on files. For instance, look at this sequence of commands:

 C:\Users\Jesper\Downloads>icacls test.txt /save acls.bin processed file: test.txt Successfully processed 1 files; Failed processing 0 files C:\Users\Jesper\Downloads>icacls test.txt /restore acls.bin test.txt\test.txt: The system cannot find the path specified Successfully processed 0 files; Failed processing 1 files C:\Users\Jesper\Downloads>icacls . /restore acls.bin processed file: .\test.txt Successfully processed 1 files; Failed processing 0 files 

Here we create a save file by pointing icacls at a file. We then try to restore it by simply substituting /restore for /save. This fails for the reason just mentioned-the restore command operates on directories only. The files it is supposed to modify are specified in the acls.bin file already. To restore the ACL we point it at the directory instead of the file. This we do in the last command where we specify "." as the object to operate on-"." obviously being the current working directory.

Substitute SIDs

Another very useful feature in icacls is the ability to replace the permissions for one user with permissions for a different user. This is done during restore using the /substitute switch. The documentation for the substitute switch says it needs an SID, but further down it explains that this can actually also be a regular user name. Thus, the following sequence works:

      C:\Users\Jesper\Downloads>icacls test.txt      test.txt VistaRC2-Test\foo:(R,W)               VistaRC2-Test\Jesper:(I)(F)               NT AUTHORITY\SYSTEM:(I)(F)               BUILTIN\Administrators:(I)(F)      Successfully processed 1 files; Failed processing 0 files      C:\Users\Jesper\Downloads>icacls test.txt /save acls.bin      processed file: test.txt      Successfully processed 1 files; Failed processing 0 files      C:\Users\Jesper\Downloads>icacls. /substitute foo bar /restore acls.bin      processed file: .\test.txt      Successfully processed 1 files; Failed processing 0 files      C:\Users\Jesper\Downloads>icacls test.txt      test.txt VistaRC2-Test\bar:(R,W)               VistaRC2-Test\Jesper:(I)(F)               NT AUTHORITY\SYSTEM:(I)(F)               BUILTIN\Administrators:(I)(F)      Successfully processed 1 files; Failed processing 0 files 

As you can see, we have the exact same ACL as we did before, but the ACE that used to specify permissions for foo now specifies them for bar instead.

Change Owner

The chown tool has been a staple in Unix for years. Windows originally had no built-in way to change the owner of an object. Then came the setowner tool in the resource kit. Then came the takeown tool in the OS, but it only allowed you to take ownership, not grant it to others unless you had their password. Finally, you have icacls with the ability to set the owner of objects you have permission to set the owner on:

      C:\>icacls c:\test /setowner foo      processed file: c:\test      Successfully processed 1 files; Failed processing 0 files 

Unfortunately, icacls can neither show you the owner of an object, nor provide you with any further indication that your request to change the owner works than the "Successfully processed …" message. This seems to be a grave oversight. There is no way to actually see, from the command line, who the owner of an object is. Furthermore, if you save the ACL for an object, it does not save the owner of the object.

There is also a bug in icacls in that it does not invoke the SeTakeOwnership-Privilege to change the owner. If you have the right to change the owner of an object based on the ACL, icacls works as it should. However, if you are an administrator, but you do not have permission to change the owner based on the object's ACL, you cannot use icacls to do so. In that case you need to use the takeown.exe tool, which does invoke the SeTakeOwnershipPrivilege, but can change the owner only to your account or the Administrators group, not to an arbitrary account:

      C:\>takeown /f c:\test      SUCCESS: The file (or folder): "c:\test" now owned by user "JJ-      VistaRTMTst\Jesper". 

Find All Aces Granted to a Particular User

Icacls has another very useful function: It can find files that have permissions for particular users. For example:

      C:\windows\system32>icacls "c:\program files" /findsid jesper /t      SID Found: c:\program files\Passgen\passgen.exe.      Successfully processed 1808 files; Failed processing 0 files 

This could be very useful if you are trying to find out what a particular user might have access to.

Resetting ACLs

If an ACL has become corrupted, or destroyed, icacls has a way to reset it to inherit from its parent. This is actually something that would have been extremely useful in the fall of 2006. One way to mitigate a recent zero-day security issue in a Windows component was to deny Everyone access to the object. That part was easy, but removing that ACE was impossible using builtin tools in Windows XP and Server 2003. In Windows Vista, you would have merely run this command:

      C:\windows\system32>icacls "c:\program files\directory\file.exe" /reset      processed file: c:\program files\directory\file.exe      Successfully processed 1 files; Failed processing 0 files 

Grant/Deny/Remove

Icacls, of course, has all the standard grant/deny/remove operations. The only really new item in that list is the remove operation. Using that switch, you can remove all allow ACEs, all deny ACEs, or both for a given user from a specific object or hierarchy. For example:

      ilC:\>icacls c:\test /grant foo:(F)      processed file: c:\test      Successfully processed 1 files; Failed processing 0 files      C:\>icacls c:\test      c:\test JJ-VistaRTMTst\foo:(F)              BUILTIN\Administrators:(I)(F)              BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)      Successfully processed 1 files; Failed processing 0 files      C:\>icacls c:\test /remove:g foo      processed file: c:\test      Successfully processed 1 files; Failed processing 0 files      C:\>icacls c:\test      c:\test BUILTIN\Administrators:(I)(F)              BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)      Successfully processed 1 files; Failed processing 0 files      C:\>icacls c:\test /deny foo:(F)      processed file: c:\test      Successfully processed 1 files; Failed processing 0 files      C:\>icacls c:\test      c:\test JJ-VistaRTMTst\foo:(N)              BUILTIN\Administrators:(I)(F)              BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)      Successfully processed 1 files; Failed processing 0 files      C:\>icacls c:\test /remove:d foo      processed file: c:\test      Successfully processed 1 files; Failed processing 0 files      C:\>icacls c:\test      c:\test BUILTIN\Administrators:(I)(F)              BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)      Successfully processed 1 files; Failed processing 0 files 

The ability to remove only the deny ACEs can be very useful if you want to open access to an object up to a particular group or user.

Set Integrity Level

Icacls also has the ability to display and set integrity levels. As we discussed in Chapter 3 and earlier in this chapter, Windows Vista supports integrity labels on objects. That means there must be a command-line tool to do so, and icacls is it.

      C:\>icacls c:\test /setintegritylevel high      processed file: c:\test      Successfully processed 1 files; Failed processing 0 files      C:\>icacls c:\test      c:\test BUILTIN\Administrators:(I)(F)              BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)              Mandatory Label\High Mandatory Level:(NW)      Successfully processed 1 files; Failed processing 0 files 

Note that icacls displays an integrity label only if an object has one explicitly set. Most files do not, so it is rare that you see one.

ACL UI

ACL UI, or the ACL User Interface, is a term that describes the graphical user interface (GUI) used to manage ACLs. It has been modified slightly from the one in Windows XP. In Figure 5-4 you see the ACL UI dialog box from Windows XP.

Figure 5-4: ACL UI dialog box in Windows XP

Compare the ACL UI dialog box in Figure 5-4 with the same dialog box from Windows Vista, shown in Figure 5-5.

Figure 5-5: ACL UI dialog box from Windows Vista

As you can see, there are a few changes here. First, the dialog box finally shows the object you are operating on very clearly, which can be useful if you are working on several objects at a time. Second, there is a hyperlink to offer some help at the bottom. However, the most notable change is in the removal of the Add and Remove buttons, which are replaced with an Edit button. The Edit button is largely present in support of UAC (see Chapter 4). As you can see by the shield on the button, the user that launched this dialog box is not running with an administrative token, and therefore will require elevation before she can edit the permissions. If the user has permission to modify the ACL, the shield would not be present. That shield signifies a COM Moniker, which we discussed in Chapter 4. If you click the Edit button, you get the familiar elevation dialog box, and if you click yes, you get a dialog box that is almost identical to the one you get in Windows XP by default. In several places ACL UI follows this "dual dialog" concept. You get one dialog box until you elevate, and once you do, you get the dialog box you are used to from earlier versions of Windows.

If you click the advanced button and then the Auditing tab you will always get an elevation button, as shown in Figure 5-6.

Figure 5-6: Modifying the audit settings in Windows Vista always requires elevation.

You cannot modify auditing without elevating, even if you have full control over the object and you are the owner. The ability to modify an object SACL is governed by the SE_SECURITY_NAME privilege, known as "Manage auditing and security log" in the GUI tools. Only administrators have that right by default, however, the privilege is removed from an admin in admin approval mode, necessitating the elevation if you are an administrator.

One final note on the elevation needs when you modify ACLs: All these statements are contingent on your not disabling UAC. If you disable UAC, all behavior reverts to the one you had in Windows XP, with the exception that the dialog boxes will look different. However, no elevation will be required, provided you log on as an administrator because your token will now have the Administrators SID in it all the time.

Other Tools

While icacls is a very useful tool, and a grand improvement over cacls, it still suffers from some shortcomings. Perhaps the most notable is that it cannot manage access to any other objects than files and directories. Windows Vista makes very sparse changes to the ACLs to other objects, compared to Windows XP, but there are still occasions when you want to manage ACLs on a service, a registry key, or even an Active Directory object.

If you are a command-line junkie, you need subinacl to do this. Subinacl is in the support tools, and is also available as a free download. Go to http://www.download.microsoft.com and search for subinacl to find the most recent version. We have to warn you, however, that subinacl is not easy to use. In fact, it is downright obtuse at times. However, there is no more powerful tool to manage access control available. If you are a power admin, you really need that one.