Things WIC ACEs Can t Do

Seeing Processes in Action

Now that we're conversant with the ways that objects, users, and processes get their integrity levels, let's try them out to see for ourselves how they work. Here are a few step-by-step demonstrations of integrity levels in processes.

Setting Up

We'll do these examples pretty much as before. In addition to Vista, you'll need chml.exe and Process Explorer. Once you've got those, get set up like so:

1. Open up two command prompts: one elevated, one not.

2. Change their default directories to C:\mystuff.

3. Start up Process Explorer with a high integrity token by right-clicking it and choosing "Run as administrator."

4. Now view the setup with Process Explorer. You should see two instances of cmd.exe, which is the Command Prompt. One will be running at medium integrity level, and the other at high.

Example: Starting a Low Integrity Application

Next, let's see how to create a low integrity process, and see how an EXE file's integrity isn't always the sole determinant in its process integrity. There isn't a nice command-line tool to launch any given application as a low integrity process, which is kind of odd, as I'd have guessed that cmd.exe or the start command would have contained that ability. But we've got our own tool to accomplish this: chml.

1. From the elevated command prompt, copy cmd.exe to mystuff by typing copy C:\windows\system32/cmd.exe and press Enter.

2. Then create a couple more copies by typing

    copy cmd.exe lcmd.exe copy cmd.exe hcmd.exe 

3. Next, let's set their mandatory labels to "low" and "high," respectively, by typing

    chml lcmd.exe -i:l -b chml hcmd.exe -i:h -b 

   In case that font isn't clear, the first chml's -i: option is followed by a lowercase "L." Both commands should succeed, as long as you ran them from the elevated command prompt. Now we've got a high-integrity cmd.exe and a low-integrity one. In the nonelevated command prompt, type hcmd and press Enter. The only output you'll get will be a line or two of copyright and Windows version information, like

    Microsoft Windows [Version 6.0.9421] Copyright © 2006 Microsoft Corporation. All rights reserved. C:\mystuff> 

   So we started up a copy of Command Prompt whose file had a high integrity level and ran it from a medium integrity command prompt… what integrity level does this new process have? Well, we expect that anything started from a medium integrity level process won't be able to run any higher than medium integrity, as UAC hasn't popped up the Consent UI, but let's check it out: type whoami /groups /fo list and press Enter.

   What happened? The last group reported was probably the Mandatory Label section, with "Mandatory Label\Medium Mandatory Label" reported, so things worked as expected, and hcmd.exe ran as medium integrity despite its file integrity.

4. Now try lcmd; in the unelevated command prompt window that you just did the whoami in, type lcmd and press Enter. Again, you should see the copyright and version notice, and a prompt. Again, type whoami /groups /fo list.

What did you get this time? If all went well, that last group was "Mandatory Label\Low Mandatory Label," with a SID of S-1-16-4096. Mission accomplished, we've got a low-integrity command prompt running!

Tip 

By the way, if you don't want to pick through all of the groups when doing a whoami /groups /fo list to find the one with the "Mandatory Label" line in it, just type whoami /groups /fo list | find “Label” and press Enter. The "find" filter is case sensitive, so be sure to type "Label" rather than "label."

Internet Explorer Protected Mode and WIC

You've already read that the version of Internet Explorer 7 that comes with Vista has something called "Protected Mode" that is, as far as I can see, one of the main reasons why Windows Integrity Control exists in the first place.

Vista's Internet Explorer 7-and the "Vista" part is important, as the version of IE 7 that runs atop XP SP2, 2003 SP1, and 2003 R2 does not behave in the same way-splits itself into two processes, iexplore.exe and ieuser.exe. (A close look back at Figure 4.2 will verify that.) iexplore.exe runs in low integrity, and ieuser.exe runs in medium integrity. Most of the surfing happens with iexplore.exe, which cannot write to anywhere except the Temporary Internet Files folder and the other low-integrity folders that I listed earlier. That's also true for IE 7 add-ons, so even if you load some malware, then it will only run in low integrity and so will be limited in what it can damage, although it can still read any file that discretionary ACLs don't block it from reading. (We'll see how you can change that later, to tighten up security a bit.) Further, IE 7 by default will not load an ActiveX control unless it's signed, so at least if you get some malware you'll know who wrote it!

But while touting the benefits of Internet Explorer 7, Microsoft doesn't always make clear that all of these benefits from low integrity only come when running Internet Explorer in Protected Mode, so it's important to be aware of when you are aren't using it. Take a look at Figure 4.3 to see what I mean.

Figure 4.3: Internet Explorer 7 in Protected Mode

The important point is on the status bar at the bottom of the window frame, where you see "Protected Mode: On." It's on by default, although you can turn it off by clicking Tools Internet Options and then clicking the Security tab to show something like Figure 4.4.

Figure 4.4: Enabling/disabling IE 7's Protected Mode

Now, that looks like the old IE security tab we've seen many times, but look below the slider on the left of the figure, and notice "Enable Protected Mode (requires restarting Internet Explorer)." Shutting it off is as easy as that, and you don't want users doing that. I don't think it'll be that long before we see websites trying to get people to shut off Protected Mode with enticements like "oh, sorry you can't see the pictures of the naked people because Protected Mode is blocking IE from showing them. Follow these directions to disable Protected Mode…." You can keep them from doing that by enabling the group policy setting in Computer Configuration Administrative Templates Windows Components Internet Explorer Security Page Internet Zone named "Turn on Protected Mode." If you turn this on, then the users can no longer disable Protected Mode.

Using the setup that we've already got running, you can verify the main effect of disabling Protected Mode-losing iexplore.exe as a low integrity process:

1. Start up Internet Explorer.

2. Look in Process Explorer if you've still got it running, and if not, then start it elevated, and note that iexplore.exe runs in low integrity.

3. Then in Internet Explorer, click Tools Internet Options and then the Security tab.

4. Uncheck "Enable Protected Mode (requires restarting Internet Explorer."

5. Click OK and then click OK on the resulting message box that says, "The current security settings will put your computer at risk."

6. Close and then restart IE.

7. Refresh Process Explorer by pressing F5.

8. Now you can verify that without Protected Mode, both IE components run in medium integrity level.

The point here was to underscore that if you disable Protected Mode in Internet Explorer, then you basically strip away the biggest part of the anti-spyware, anti-malware improvements that Vista offers. If you need to visit specific websites that cannot work in Protected Mode, then just put them in your "Trusted sites" zone because if you turn back to the Security tab of Internet Options on IE, notice that if you click between the Internet, Local intranet, Trusted sites, and Restricted sites zones, then you'll see that you can choose to enable or disable Protected Mode just for those zones and, in fact, by default the Trusted sites zone does not enable Protected Mode.

Tip 

Another way to disable Protected Mode is to start Internet Explorer from the command line on an elevated command prompt.

A Prime Directive Puzzle: WIC and Deletes

Remember what I call "Windows Integrity Control's Prime Directive?" It says that "no process can modify an object with a higher integrity level." We saw that in action much earlier in this chapter when we created a file named hltest.txt and set its integrity level to high, and then opened it in Notepad. Recall that when we tried to save the file, Notepad couldn't, because Notepad was running as a medium integrity level process and was trying to modify a high integrity level process. That was a nice demonstration of the Prime Directive.

But now try this one.

If you've still got hltest.txt around, great; if not, just redo the steps in the earlier exercise. Then, from the unelevated command prompt,

1. Type whoami /groups /fo | find “Label” and press Enter to verify that you are indeed running with medium integrity level.

2. As you created this folder, you can give yourself full control of it, so let's do that by typing icacls C:\mystuff/grant yourusername:(f) and press Enter.

3. Finally, type erase hltest.txt and press Enter.

   Note the distinct lack of an "access denied." Look in the folder, hltest.txt is gone, gone, gone! Now, I know that some of you folks who are just sitting and reading this without trying it out are skeptical, so consult Figure 4.5 if you are in doubt.

   
   Figure 4.5: A medium integrity process deletes a high integrity object!

Testing File Delete Permissions with icacls

How the heck did that happen? The answer lies not in some new feature or bug in Vista, but in an old fact of life for permissions: the permissions for deleting files are looser than for almost anything else in NTFS. Where it's possible to, say, keep someone from reading a file once and for all by applying a single ACE to that file that says, "deny the ‘read’ permission to such-and-such person," you can't do that with file deletion.

Here's an outline of a more specific example that you can try out to prove it to yourself on any system, from NT 3.1 up to Vista:

1. Create a folder.

2. As you are the owner of the folder, you can give yourself full control of the folder; do that.

3. Inside the folder, create a file.

4. As you are the creator of the file, you can deny yourself the right to delete the file; do that.

5. Try to delete the file; it will succeed.

   All of that's easy enough to do from the GUI, but describing how to do it's a whole lotta clicking and dragging and, besides, I love preaching the Gospel of the Command Line, so if you'd like to try it, then start up an unelevated command prompt and type these commands. Where I've typed "mark," the account that I'm logged in as, just substitute your username. Start from C:\mystuff so you've got createfile close to hand.

 md C:\test icacls C:\test /grant mark:F createfile C:\test\killtest.txt icacls C:\test\killtest.txt /deny mark:(D) erase C:\test\killtest.txt 

Most of those commands should be clear-md makes directories or, as we've come to say since Windows 2000, "folders," createfile creates a simple text file, and erase erases a file. icacls lets me modify permissions of all types and its syntax looks like

 icacls objectname /grant|/deny username :permission 

That looks a little ugly but let's pick it apart to see how it works. objectname is just the name of the file or folder that we want icacls to work on. Use /grant to create a new "allow" ACE, or /deny to create a new "deny" ACE. username is whomever you want to give this new ACE to, and-here's the only troublesome part-permission is a set of one or more one- or two-character "codes" that refer to one of the 12 low-level file permissions or 13 low-level folder permissions. You can find them in the following Table 4.2.

Table 4.2: Permission Codes
Open table as spreadsheet

If this refers to a file, then it means…	If this refers to a folder, then it means…	Code
If this file is an executable, allow the user to execute it	Bypass traverse checking	X
Read the data in this file	List the files and folder in this folder	RD
Read the basic attributes of this file (system, hidden, read-only, archive)	Read the basic attributes of this folder (system, hidden, read-only, archive)	RA
Change the basic attributes of this file (system, hidden, read-only, archive)	Change the basic attributes of this folder (system, hidden, read-only, archive)	WA
Read the extended attributes of this file (author, copyright, description, rating-basically any of the Vista "tags" or "metadata")	Read the extended attributes of this folder (author, copyright, description, rating-basically any of the Vista "tags" or "metadata")	REA
Change the extended attributes of this file (author, copyright, description, rating-basically any of the Vista "tags" or "metadata")	Change the extended attributes of this file (author, copyright, description, rat-ing-basically any of the Vista "tags" or "metadata")	WEA
Change permissions on this file	Change permissions on this folder	WDAC
Read permissions on this file	Read permissions on this folder	RC
Delete this file	Delete this folder	D
Write or change the data in this file	Create a new file in this folder	WD
Append data to an existing file	Create a new subfolder in this folder	AD
Change this file's owner	Change this folder's owner	WO
	Delete files and folders in this folder (short for "delete child," as objects inside folders are called "child objects")	DC

You can include more than one permission; just separate them with a comma. For example, to give the account "jane" the ability to read permissions, write permissions and take owner-ship-recall that's the set of permissions that an account would need in order to modify a mandatory label-then I'd type

 icacls c:\test /grant jane:(WO,RC,WDAC) 

Anyway, returning to the example above, it worked like a charm. And, for the unbelievers, I offer a screen shot of a run of this in Figure 4.6. I included a whoami/groups to prove that, again, I was running there as a standard user, not an administrator.

Figure 4.6: Mark amazingly deletes the file even though he is denied the "delete file" permission!

Denying File Deletes Is Different from Denying Most Things

What's going on here is not a Windows bug, but a design decision that Microsoft made. Consider that when you delete a file, in actuality two things happen. First, of course, you delete the actual object that is the file. But at the same time, you modify the object that is the folder.

Note 

If that's not clear, think about what a folder is. It's really nothing more than a list of the files and subfolders inside of it. Adding a file adds something to the list, deleting one subtracts one. But in both cases, you have modified the list, and the list is a securable object…so you need the proper permissions.

So if deleting a file does two things-deletes the file and modifies the information in the folder that used to contain the file-then that seems to imply that I would need two permissions to delete a file:

• The "delete" permission on the file object

• The "delete subfolders and files" permission on the folder that contains the file

Now, I'd think that you would need both of those permissions to delete a file. But not everyone agrees; for example, I've seen Unix implementations that allow someone with administrator-level control of a folder to delete a file, even if that person has no permissions to the file itself. Were I in charge of maintaining a folder full of home directories and eliminating unlawful material but I couldn't have or, for legal reasons, might not want to have access to the particular files, I could see the logic of being able to delete "stolen commercial music.mp3" or "nakedbabe.jpg" without actually being able to open them. (Another reason for this may be that standard Unix/Linux file permissions are a bit less flexible than NTFS file permissions; see Chapter 6 in my Linux for Windows Administrators for a discussion of this. That may have motivated the original Unix ability to delete a file even if you lacked access to the file.)

Whatever the reason, ever since NT 3.1 it's been the case that Windows allows you to delete a file if you have either of the two permissions. Try, for example, creating another folder with another file in it, and then give yourself "delete" permission on the file, but deny yourself the "delete subfolders and files" permission on the C:\test folder, and tell Explorer to apply that permission to "this folder only." Or you could do it from the command line as before except now I'm denying myself the "DC" permission, which is the "delete subfolders and files" permission-the "DC" stands for "delete children," a geekspeak way of saying "delete subfolders or files." Delete C:\test to start fresh and type

 md C:\test icacls C:\test /grant mark:F createfile C:\test\a.txt icacls C:\test\a.txt /deny mark:(DC) erase C:\test\a.txt 

Again, that ran fine for me and allowed me to delete killtest.txt. It is only by denying the Mark account both the "delete" permission on the file and the "delete subfolders and files" permission on the folder that killtest.txt doesn't get deleted.

How Blocking Deletes via WIC Can Fail

Okay, so now we know that keeping someone from deleting a file under NTFS has, since time immemorial (well, since July 1993), required blocking their ability to delete the actual file, and blocking their ability to delete subfolders and files in the folder that contains that file. But the original question wasn't really an NTFS permission question, was it? The original question was "if hltext.txt is a file with a high integrity mandatory label, then why can a medium integrity process delete it?" Here's why:

• As before, blocking deletion requires the file "deny" and the folder "deny." Put another way, Windows lets you delete a file if you have either a file "allow" or a folder "allow." There's nothing like in Windows permissions that I know of, as normally the first time Windows sees a "deny," the whole operation's terminated.

• There was no file "deny delete" in the hltest.txt example. Instead, there was the difference in mandatory integrity levels, which act as a "deny" and trump any discretionary ACLs. You couldn't see what was going on under the hood, but this part worked as expected, and the medium integrity process was blocked from deleting hltest.txt …

• … but Vista knew, as all versions of NT have known, that just because the file "deny" has kicked in doesn't mean that the fat lady has sung yet. So Vista said to the folder that hltest.txt was in, "do you have any problem with this medium integrity process deleting one of your files or subfolders?" Now, the folder was labeled as medium integrity (as it was not labeled), and a medium integrity folder has no problem with being modified by a medium integrity process. Result: hltest.txt is history.

  In short, Windows Integrity Controls do trump DACLs, but there was only a Windows Integrity Control to trump the file part, and none to trump the folder part.

The Solution: Ensuring That WIC Protects Objects

Now we're ready for the solution to the problem of "how can I use Windows Integrity Controls to keep lower-integrity processes from deleting higher-integrity objects." The best solution is to put items of a given integrity into folders of that integrity. Then the "delete file" attempt will fail against the higher-integrity file, and the "delete subfolders and files" attempt will fail against the higher-integrity folder.

To see this, try these commands out. As before, start with both an elevated and unelevated command prompt, both set with C:\mystuff as their default directories.

From the elevated command prompt, we'll create a subfolder of C:\mystuff called C:\mystuff\high. We'll then grant our user account full control of C:\mystuff\high and all of its contents. After that, we'll raise C:\mystuff\high 's integrity level to high. Then we'll create a file called test.txt inside that file, and it will inherit the file's high integrity level. Finally, from the unelevated-medium integrity-command prompt, we'll try to delete test.txt, and verify that it fails.

First, move to the elevated command prompt and type these commands:

 md C:\mystuff\high icacls C:\mystuff\high /grant yourusername:(OI)(CI)F chml C:\mystuff\high -i:h -b createfile C:\mystuff\high\test.txt 

Then, move to the unelevated command prompt and type erase C:\mystuff\high\ test.txt. The file is erased, and you can see a sample run on Figure 4.7.

Figure 4.7: Mandatory integrity wins at last!

The moral of this story is simple: things are best secured with integrity levels if they are in a folder with similar integrity levels.