Using WIC ACEs to Restrict Access

WIC Components

Okay, thanks for sitting through the theory; time to get down to the details. Stringing together terminology and concepts, you have thus far seen that Windows Integrity Control applies mandatory labels to securable objects to declare their integrity levels, a measure of their trustworthiness. I've also said that the main effect of integrity levels is that you can configure anything to ignore attempts to read, write, or execute it when those attempts come from a process with a lower integrity level.

WIC's Six Integrity Levels

Microsoft chose six integrity levels. As far as I can see, they all get some use in Windows by default, but honestly the big one is the low integrity level. I'm simplifying, but at the moment it seems to me that most of WIC's work is in maintaining the border between "low" and everything higher than it. That's not to say that there isn't any difference between the levels or that you can't exploit them once you know what they are, so let's take a look at the six levels. Any process, user, or object can, in theory, hold any one of the following six levels, arranged in increasing order of trustworthiness:

Untrusted According to Microsoft documentation, this is the setting given to any process logged on anonymously. I've not found a way to really try this out, except in one way. As I'll demonstrate later, if you give an untrusted integrity level to a program file, any EXE, and try to run it, Windows will tell you "access denied."

Low This is the integrity level given by default to anything from the Internet. Internet Explorer runs in low by default, although you can change that by disabling a new feature of Internet Explorer 7 called "Protected Mode." When setting up your profile, Vista creates several folders with low integrity-for example, your Temporary Internet Files folder. It also sets up a few Registry keys with low integrity because the new Internet Explorer wouldn't be able to save your settings otherwise.

Medium Standard users run in this integrity level. In fact, almost every file on your computer has a medium integrity level because anything that hasn't been explicitly labeled gets the medium integrity level. That's useful because recall that WIC's first job is to protect your files from malware collected from the Internet. As "unlabeled" means "medium," that means that most malware's attempts to modify your files or folders will be rebuffed. (Well, the malware you get from the Internet. Any malware you bring into the office on a CD will run at medium or high, depending on how you're logged in when you accidentally install it!)

High Administrators run in this integrity level. Without a high integrity level, administrators probably couldn't get their jobs done, or at least it probably seemed that way when WIC first appeared. In its first incarnation, I'm told that you needed a higher integrity level than an object had to write to it. Thus, admins needed a higher integrity level than what users had.

System Humans don't run in this integrity level or, rather, there's no way to make them do it that I've figured out. System services and in fact most of the kernel seem to run in the system integrity level. That's no problem and in fact it'll serve to make services more impervious to an administrator accidentally elevating some bad malware. The worrisome part is that perhaps some day some bad guy will figure out how to write malware onto the system with the system integrity level. Just think: malware that even an administrator can't uninstall.

Installer Jumping off from a previous point, Microsoft needed the installer system to be higher in IL than anything else so that it could uninstall it due, again, to the original spec on WIC that said that a process needed a higher IL than an object in order to modify the object. (In practice, I'm not aware of any instance where you actually see anything operating as "Installer.")

Under the hood, though, you're going to see that integrity levels usually aren't as simple as "system," "high," and so on. Every integrity level can be expressed as a SID that looks like S-1-16-number, where the number varies from 0 to 16384. Each level also gets a name that looks like "Mandatory Label\ Level Mandatory Level," where Level is Untrusted, Low, Medium, or whatever. Most levels also have a two-letter code used for things encoded in something called the Security Descriptor Definition Language or SDDL.

I know that's a lot to see all at once but I promise, it'll be clearer when we see some real-live mandatory labels, SDDL strings, and the like-I promise, I'll cover all of that stuff in this chapter. For now, though, let me just offer Table 4.1 as a reference to the many guises that a given integrity level takes on-guises that we'll meet in this chapter.

Table 4.1: Summary of Types of Integrity Levels
Open table as spreadsheet

Name	Account Name	SID	Hexadecimal Value	SDDL SID string	Notes
Untrusted	Mandatory Label\Untrusted Mandatory Level	S-1-16-0	0	None	Anonymous
Low	Mandatory Label\Low Man-datory Level	S-1-16-4096	1000	LW	"Protected Mode Internet Explorer" runs in this, and any objects automatically downloaded from the Internet into Temporary Internet Files get this level's label.
Medium	Mandatory Label\Medium Mandatory Level	S-1-16-8192	2000	ME	Users run here and anything without a label (i.e., system files) have an assumed IL of ME. Files that standard users download from the Internet with "save as" get this level.
High	Mandatory Label\High Man-datory Level	S-1-16-12288	3000	HI	Administrators run here.
System	Mandatory Label\System Mandatory Level	S-1-16-16384	4000	SI	Most system services run here.

How Objects Get and Store Integrity Levels: Mandatory Labels

Vista stores integrity level differently for processes, users, and objects. Vista stores an object's integrity level inside a special System Access Control Entry (SACE, pronounced to rhyme with "ace"), which is on that object's System Access Control List (SACL, pronounced to rhyme with "ACL").

The SACL: It's Not Just for Audits Anymore

"SACL" and "SACE" don't ring any bells or, perhaps, the bells tinkle but a mite faintly? Given how little they've done for us since NT 3.1's appearance, that'd be no surprise. If you've ever audited object access, however, then you've used them. In addition to space for a discretionary ACL, every securable object has space for a system ACL. Don't go looking in the Orange Book, Common Criteria, or the like for SACLs-they're not there. But back when they were working on NT 3.1, Microsoft said "hey, as long as we're creating places for the DACLs we need for that C2 certification, why not leave one for our own purposes?" and so they added a SACL.

Microsoft envisioned using the SACL and its component SACEs for many things, but the only thing that SACLs have ever held have been instructions about what to audit. Most of the nine things that Microsoft lets you audit, like logons, use of privileges, system events, and the like consist of nothing more than just on/off switches in group policies that enable or disable some class of audits. But if you flip "Audit object access" on, you won't get any information in the Security event log because you must first go to every object for which you'd like Windows to track access and describe how specific you'd like Windows to be in reporting that access. For example, suppose you want Windows to watch activity on a particular file. You can't just tell Windows, "watch all access attempts on the file test.txt"-that's not enough information by half. Windows wants to know, "who should I report on, and what kind of activity should I report on-when she tries to read? Write? Change an attribute? And should I report the successes, failures, or both?" As anyone who's ever done object access auditing knows, you've either got to be very specific about what you'd like to see, or face mountains of audit logs. Anyway, when you specified exactly who you wanted watched, what activities you wanted watched, and whether you wanted successes, failures, or both tracked, then that information went into the SACL as one or more SACEs and, from 1993 to now, that's about the only use the SACEs and SACLs have had.

Tip 

You can see the SACEs on any object by right-clicking it, then choosing Properties. In the property page that appears, click the Security tab and then the Advanced button. In the dialog box that raises, click the Auditing tab-in Vista, you'll have to first click a Continue button to make User Account Control happy-and you will, on the resulting page, see any SACEs on that object. In most cases, however, it'll be empty, as most folks don't do much object auditing.

WIC's Mandatory Labels: Lost in SACE

"Danger, danger, Will Robinson!" (Sorry, couldn't resist.) If you just read that tip, then you may be wondering something. After all, I've already said that (1) everything's got an integrity level in Vista, (2) it's stored as a new kind of access control entry called a "mandatory label," (3) that mandatory label ACE is actually a special SACE, and…(4) you just read that the chances are good that any given file's SACL-the list of its SACEs-is empty. Okay, Robot, now you can talk. Go ahead….

"That does not compute, Will Robinson! If all objects have mandatory labels that are actually SACES then how can their SACLs be empty urrgh…"<slight sound of thump as the Robot's head slumps forward and his lights go out when some miscreant flips his normally obscure power switch>.

I've always wanted to turn off that robot. Anyway, our metal friend is right, or at least his inference engine is, because I left off two factoids.

• First, Microsoft decided for some reason not to show the mandatory label SACE in the GUI in the Auditing tab. As far as I can see, there are no GUI tools that will show you an object's mandatory label SACEs. There is a command-line tool that we'll discuss later, but it's limited in capabilities. Meanwhile, I've written a command-line tool that does things that the built-into-Vista tool does, and more-but we'll meet that in a minute.

• Second, in actual fact the vast majority of objects in Windows have an integrity level, but it's only an implicit one. Most things do not have an actual mandatory label SACE because of the WIC Second Directive.

Note 

The Second Directive of Windows Integrity Control is "if an object doesn't have an explicit mandatory label, then treat the object as if it had a mandatory label identifying that object as being of medium integrity."

It was probably a good move on Microsoft's part to store integrity levels as something in an object's SACL, because so many kinds of objects already have SACLs. Thus, without having to replace too much of Windows' plumbing, we get a mandatory control infrastructure in addition to our already existing discretionary one.

Viewing Object Integrity Levels: Meet chml and icacls

So how do we view an object's mandatory level? Well, actually, Windows doesn't have a tool that does that. (Or at least it didn't until just a few weeks before Vista's release.) But I do.

The Tools: icacls and chml

You see, back when I was first working on this Windows Integrity Control stuff, I asked everyone at Microsoft who'd listen, "what tool shows me an object's integrity level? What lets me change an object's integrity level?" To both questions, I got a blank stare and the answer that "there is no tool that can do that." They were partly right, because there is a tool in Vista that lets you set integrity levels and, yes, it does let you view integrity levels sometimes, but not all of the time.

It seems, however, that almost no one in the Microsoft world knew of this tool, a command-line program named icacls that Microsoft intends to use to replace cacls, a command-line application that's been around since NT 3.1, if I recall right. I say that virtually no one knew about icacls because I found it when I started playing with RC1, only to find that it just plain didn't do what its Help claimed that it could do. Finally I found a helpful soul at Redmond who confirmed that yes, icacls would work by the final release, but didn't work in RC1.

It did get fixed, but only in Build 5744, which Microsoft released in mid-October. I couldn't wait that long, so I wrote my own program that did what icacls did, and (he said, modestly) a bit more. I called it "chml," for "change mandatory label." Get it like this:

1. Open up Internet Explorer.

2. In the address bar, type http://www.minasi.com/vista/chml.htm.

3. Click on the hyperlink to download chml.exe.

4. When prompted, click the Save button.

5. Save it to a folder that you can write to; the C:\mystuff folder we've been using works fine.

6. Open an elevated command prompt.

   Note 

   I took you through all of that rather than just saying "go to such and such URL and save this to C:\windows" because Internet Explorer runs in low integrity and Explorer runs in medium integrity and cannot write files to the Windows directory; in contrast, from an elevated command prompt, you can. It's just part of getting used to Vista. Another perfectly good approach is to save chml.exe to some folder and modify your system's path to include that folder.

7. Change directory to C:\mystuff with cd \mystuff.

Viewing Integrity Levels with chml

1. From the elevated command prompt, type copy chml.exe C:\windows so that it'll be somewhere that we can get to from any directory.

2. Then query notepad.exe by typing chml C:\windows\notepad.exe, like this:

    C:\mystuff>chml C:\windows\notepad.exe -b C:\windows\notepad's mandatory integrity level=unlabeled (medium) 

   Notice that chml tells you that notepad.exe has a medium integrity level, but that it comes by that integrity level by default.

3. To see one with an explicit integrity level, type chml C:\users\yourusername\appdata\locallow -b, and press Enter, where you should substitute your username for "yourusername". For example, I'm logged in as "mark," so running chml would look like this:

    C:\mystuff>chml C:\users\mark\appdata\locallow -b C:\users\mark\appdata\locallow's mandatory integrity level=low 

Notice two things:

• First, as promised, there are things on your computer that are low integrity right out of the box. (And when I say "low integrity," I'm not talking about the salespeople who sold you the computer. Or, God forbid, Vista Home Basic.)

• Second, notice that in this case you don't see the "unlabeled."

Viewing Integrity Levels with icacls

Let's next try those jobs out with the built-in tool, icacls. To see icacls in action, just

1. Open a command prompt, either elevated or not.

2. Type icacls C:\windows\notepad.exe and press Enter.

3. Type icacls C:\users\yourusername\appdata\locallow-and substitute your username for "yourusername" and press Enter.

   You'll see something like Figure 4.1, which I'm presenting as a screen shot rather than text because the format of icacls ' output tends to make it wrap on the page and become basically unreadable.

   
   Figure 4.1: Reading mandatory labels with icacls

Hang on, I know it's ugly, but please don't run away! Learning to interpret icacls output is important because, again, this is the only tool, GUI or otherwise, that comes with Vista and lets you examine or modify an integrity level. icacls 's output is something of a mixed bag of permission information because it

• Only shows you the contents of the discretionary ACL and any mandatory labels; anything that's in the system ACL that isn't a mandatory label doesn't show up. That means that if either Notepad or LocalLow had auditing SACEs on them, then icacls would not report them.

• Because icacls only shows you the ACEs that are actually there, it cannot tell you that, for example, Notepad has an assumed medium integrity level. But just remember, if you do not see anything with "Mandatory Label" at the beginning of it, then there's no explicit label for integrity levels, and it's treated as medium.

• The stuff that looks like (OI)(CI)(NW) is a shorthand way of describing the permissions that the ACE confers. In this case, it means

  • "Give any files in this folder an integrity level of low like the parent folder." (OI)

  • "Give any subfolders in this folder an integrity level of low like the parent folder." (CI)

  • "Do not allow any process of a lower integrity level to modify this folder." (NW)

  That shorthand is part of the Security Descriptor Definition Language that I mentioned earlier, and I will present a short guide to it a bit later.

Decoding Mandatory Labels

icacls presented LocalLow's integrity label as it did because that's the official Microsoft format for displaying labels. It looked like "Mandatory Label\Low Mandatory Level," a label that I introduced earlier but did not explain in detail. It means that

• The "domain" part of the object name is "Mandatory Label." This name derives, recall, from Orange Book talk.

• The "object name" part will be one of the following values:

  • System Mandatory Level

  • High Mandatory Level

  • Medium Mandatory Level

  • Low Mandatory Level

  • Untrusted Mandatory Level

Note 

You may recall that there is another level, the "Installer" or "Trusted Installer" level, but I didn't name it in the above list. Honestly I've never seen an object that runs at that level-it's an integrity level given only to processes as far as I can see-so I can't report what, if anything, icacls would report for such an object. I have seen the other labels, however.

In case this "Mandatory Label\Low Mandatory Level" doesn't make sense, yet compare it to another ACE as presented by icacls, the first one on "LocalLow." icacls presents it as

 Vista64\Mark:(F) 

In comparison, icacls shows the mandatory label like so:

 Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) 

In general, ACEs confer permissions, and, simplified, there are two parts to every permission: who's getting the permission (the "trustee" in Microsoft terms), and what level of permission he's getting, like "full control" or "Read" or the like. In icacls output, the trustee is on the left side of the colon, like "Vista64\Mark," and the permission amount is on the right of the colon, as in "(F)," which means "full control."

Now, mandatory labels, the SACEs where Microsoft stores information on integrity levels, don't really fit into that model because the trustee, the thing that's getting the label, is obvious: it's whatever object the SACE is on. In "Vista64\Mark," the "Vista64" part is essential, as it identifies where to find the computer that holds the Mark user account. But mandatory labels are domain and computer-independent. Given that, all that a mandatory label need convey is the integrity level that the object has. But the fact is that because Microsoft was trying to use an existing storage mechanism for the mandatory labels-a SACE-then they had to make the data fit into that container's rules, and, again, the rules are that the absolute minimum amount of information that any ACE needs is "who gets this?" and "what do they get?" Normally that first part is expressed as a combination of an account name and the domain or local system that the account lives in, but that really didn't make sense here, so Microsoft just arbitrarily gave it a "domain name" of "Mandatory Label."

Note 

Technically, the thing on the left-hand-side of the backward slash, whether it's a local system name, a domain, or "Mandatory Label," is called the "authority" that issued the name.

Changing Object Integrity Levels

From the beginning I've been kind of twitchy about this whole idea of stuff that I can't change, so I was very, very interested in discovering what, if anything, I could do to change an object's integrity level. Here's the short version:

• Users can change an object's integrity level if they have a new-to-Vista user privilege known in Microsoft privilege as SeRelabelPrivilege that lets them modify an object's mandatory label.

• Any user with that privilege will get a split token when logging on, as that privilege is one of the Notorious Nine, as you read in Chapter 2.

• Anyone wanting to read an object's mandatory label only needs "read permissions" on the object. To change an integrity level by modifying a mandatory label, that user would also need "change permissions" and "take ownership" on that object.

• Users with SeRelabelPrivilege can raise or lower an object's integrity level, but they cannot raise that object's integrity level above their own.

Let's take these in turn so that we can start messing with integrity levels.

The New "Modify an object label Properties" Privilege

Recall that mandatory controls, as laid out in the Orange Book and similar standards, can be "mandatory" in varying degrees. In their weakest form, they might be nothing more than rules created by administrators to restrict the discretionary powers of standard users; in the extreme they could be iron rules built right into the operating system that no one can change. Windows' implementation of Windows Integrity Controls is somewhere in the middle, and permits administrators to loosen or tighten things a bit.

Right out of the box, Vista's Windows Integrity Controls are unbending-if something is of medium integrity, it's staying that way. But that changes if you grant the right to change mandatory integrity levels to someone-and heck, why not yourself? The new privilege's English name is "Modify an object label," short name SeRelabelPrivilege. Here's how to get it.

Warning 

You'll need local administrative powers to modify your user rights to make this work, as has been the case since Windows 2000. If your test machine is a member of an Active Directory domain and your domain admin has locked down your user rights, then you'll either have to go talk to her, just follow along with the screen shots, or set up a stand-alone test system that's not a member of the domain to do this stuff. I am a huge fan of virtual machines for this kind of stuff, and both Microsoft and VMWare offer very nice and free virtual machine managers. Personally, I like VMWare Workstation, even though it runs just under $200. It has repaid its cost over and over and over….

1. Open up your system's local Group Policy Object Editor. Either type gpedit.msc from a command line, or click Start All Programs Accessories Run… and fill in gpedit.msc and click OK.

2. Click Confirm at the Consent UI unless you've disabled UAC or you've started gpedit.msc from an elevated command prompt.

3. Navigate to Computer Configuration Windows Settings Security Settings Local Policies User Rights Assignment.

4. Scroll down to find "Modify an object label." Double-click it.

5. In the resulting "Modify an object label Properties" dialog box, click the Add User or Group button.

6. In the resulting field labeled "Enter the object names to select," type in your username, or perhaps just punch in Administrators to give all local administrators this privilege. (If you do enter Administrators, though, be sure to click the Object Types button on the right-hand side of the dialog box so that you can check the check box next to Groups. For some reason by default the User Rights Assignment area of group policies only wants you to enter usernames rather than groups. By checking this box, it'll accept a group name.) Click OK until you get back to the Group Policy Object Editor.

7. Close the Group Policy Object Editor.

   At this point, you've got the privilege on your account, but not your token. So don't forget Windows Security 101: log off and log back on to give Windows a chance to include that new privilege in your token.

Permissions Needed to Change an Integrity Level

Before you can change an integrity level, you'll need some permissions-but how much? Recall that integrity levels are implemented as system access control entries, and "access control entry" is just another word for "permission." You may also know that files have 12 low-level permission types and folders have 13, and in both cases there are specific permissions named "read permissions" and "change permissions"-permissions about permissions, you might say. Therefore, it's no surprise to hear that reading an object's integrity level requires only the "read permission" permission.

Changing an integrity level, however, is a bit of a surprise. You need the "change permission" permission, of course, but you also need the "take ownership" permission. Why? Because one of the other 12 or 13 low-level permissions is "take ownership." Therefore, anyone who can change an object's permissions can give herself ownership of a file, and ownership is of course a pretty big thing. Therefore Vista requires not only "change permission" permission to modify an integrity level, but the "take ownership" permission as well.

Changing an Object's Integrity with chml

Once you've gotten SeRelabelPrivilege and have sufficient permissions (you already did, so there's nothing to do in this case), and have chml.exe in C:\windows so that it's on your path, you can take chml out for a spin, but this time, we won't just look at integrity levels…we'll change them. For this exercise, let's continue working in C:\mystuff, so open up an elevated command prompt and a nonelevated command prompt, and navigate to C:\mystuff on both of them with cd \mystuff. Then dig out the createfile program from vistafiles.zip, which recall you downloaded from http://www.minasi.com/vista in Chapter 2 and do this:

1. From the unelevated command prompt, type createfile hltest.txt and, of course, press Enter. You've now got a simple text file named hltest.txt.

2. Verify that you can modify this file by opening it with Notepad. Change a character or two, save the file, and close Notepad.

3. Examine its mandatory integrity level by typing chml hltest.txt -b and pressing Enter. You'll see that it has a medium integrity level because we haven't given it a mandatory label yet.

4. Now switch over to the elevated command prompt.

5. Raise hltest.txt 's integrity level to high by typing chml hltest.txt -i:h -b and pressing Enter. You should get a response like

   Integrity level of hltest.txt successfully set to high.

   Note 

   chml's syntax for changing integrity levels is "chml filename -i: level," where level can be u, l, m, h, or s for untrusted, low, medium, high, and system, respectively. "s" won't work, though, because you're only running at a "high" integrity level. (It's in there because I'm hoping to figure out how to make it work one day.)

6. Use icacls to verify that you've raised hltest.txt 's integrity level by typing icacls hltest.txt and notice the line saying "Mandatory Label/High Mandatory Level" label. You can see a similar result by running chml hltest.txt -b.

Changing an Object's Integrity with icacls

icacls finally started working with Build 5744 as I was finishing the book, so I can show you how to change a file or folder's integrity level with this syntax:

 icacls filename /setintegritylevel H|M|L 

To which icacls will respond

 processed file: filename Successfully processed 1 files; Failed processing 0 files. 

So, for example, to change hltest.txt 's integrity level to low, you'd type

 icacls hltest.txt /setintegritylevel L 

As with chml, changing a file's integrity level requires having SeRelabelPrivilege, an elevated command prompt, and both "change permissions" and "take ownership" permissions on hltest.txt.

Testing Out WIC's Prime Directive

Back when we started discussing this topic, I said that the big payoff about WIC was that lower-integrity processes could not modify higher-integrity objects. Now that we've got a file that's got a high integrity level, let's see what might happen if we try to mess with that file.

1. Start Notepad from the Start menu, not your elevated command prompt, and read C:\mystuff\hltest.txt. Now, because you started Notepad from the Start menu in the usual way, then it will get your standard user token, assuming that you haven't disabled UAC. (If you did, then most of what you'll see here won't work.) Forgive me for jumping ahead a bit, but please just trust me when I say that Notepad is running at medium integrity level right now.

2. Change the text a bit.

3. Click File Save to save the file.

   Notepad will complain that it "Cannot create the C:\mystuff\hltest.txt file; Make sure that the path and file name are correct." That's Notepad's less-than-clear way of saying, "I got an Access Denied message from the operating system when I tried to write out a new hltest.txt file." Now let's demonstrate that Notepad can modify hltest.txt, when Notepad's got the right integrity level.

4. Click OK to clear the error dialog, Esc to clear the File Save dialog, and close Notepad, choosing "Don't save" when it asks you what to do with the changed file.

5. Now start up Notepad by clicking Start All Programs Accessories and then right-click Notepad and choose "Run as administrator."

6. Click Continue at the UAC prompt. Again, we'll cover this in more detail soon, but for the moment let me note that Notepad now runs in high integrity.

7. Open C:\mystuff\hltest.txt.

8. Modify the text again.

9. Click File Save. Notice: this time, no errors, as the process (Notepad) had an integrity level equal to or greater than the object (hltest.txt).

10. Exit Notepad.

    Summarizing, here's what we've seen in this section and with these exercises:

• You can raise or lower an object's integrity level so long as you've got SeRelabelPrivilege and are running as an administrator. You've got to be running elevated with "Run as administrator" because you may recall that SeRelabelPrivilege is one of the Notorious Nine privileges that get removed from your standard user token.

• You must have the "read permissions," "change permissions," and "take ownership" permissions on an object to view and modify its integrity level.

• You can use chml or icacls to make the change.

• You can raise or lower any object's integrity level as high as your integrity level, and no higher.

By the way, if you've sat through or read some of the early material from Microsoft about Windows Integrity Controls, then you may have heard that users with the "modify an object's label" privilege could only lower an object's integrity level. That may have been true for early betas of Vista, but it's not true now. As you'll learn later, the highest integrity level that a user can get is High, so that's as high as you'll ever raise an object's integrity.

Warning 

I know what you security expert types are thinking. "No problem, I'll just schedule an integrity-changing command via the at.exe program and, as at.exe runs under LocalSystem-which runs at the system, not the high, level-then it can raise an integrity level all the way to system. Or perhaps I'll have that run in a Startup script, as that runs at LocalSystem." As the folks say where I grew up in New York, fuhggedaboutit. Microsoft's apparently read a couple of those "how to hack Windows" books and plugged those holes, dagnabbit. I think there might be a way to build a service-services run as system integrity-but I'm not a good enough programmer to write one of those. Also, I suspect that Microsoft has thought of that as well.

Default Low Integrity Folders

Before moving along to examine how users and processes get integrity levels, let me mention a few cases where Vista's designers have made use of the ability to set integrity levels on folders. They're there in support of Protected Mode Internet Explorer:

• \Users\ username \AppData\LocalLow,

• \Users\ username \AppData\Local\Temp\Low, and

• Several objects in \Users\ username \AppData\Local\Microsoft\Temporary Internet Files\Low (which is a System file, so you won't see it by default)

User Integrity Levels

We've just seen how objects get and store integrity levels. Next, let's take on user accounts to see where they get their integrity levels.

User Integrity Levels Depend Solely on Privileges

As far as I can see, users in the Vista world can only get either a high integrity level or a medium one, although I imagine that there might be cases where someone might log onto a Vista box anonymously, which would get them an "untrusted" integrity level. But which do you get, high or medium? Basically, anyone running with a standard user token will have a medium integrity level, and anyone running with an administrator token gets a high integrity level. But why does that happen?

Well, recall from Chapter 2 that User Account Control gives you a split token when you log on if you're either a member of the Fearsome Four local groups or have one of the Notorious Nine user privileges. I therefore expected that if I turned off UAC altogether, created a user, and added it to, say, Network Configuration Operators-one of the Fearsome Four-then when I logged it on, it'd have a high integrity level. (I'll show you how to determine your integrity level in a moment.) I was surprised to find that the user account ran at medium. I got the same result for adding the user account to Power Users, another member of the Nine-a user that's a member of Power Users and Network Configuration Operators runs just as a medium integrity user.

But add that user to either the Backup Operators or Administrators group, and its integrity shoots up to high. The rules for assigning a user an integrity level, then, seem to be quite simple:

• In determining your user account's mandatory integrity level, your group memberships don't count. The Fearsome Four are irrelevant save in a backhanded way, because…

• What does matter is the set of user privileges that you enjoy. If your user account includes any members of the Notorious Nine, then your logon gets a high integrity designation for this session and any others where it has one of the Nine as a privilege. If it lacks all of the Nine, then it gets a medium integrity level.

Where Users Store Integrity Levels

Although user accounts are securable objects, there doesn't seem to be any way to apply mandatory labels to them, and apparently nothing good would come of doing so. So where does a user account carry its integrity level? Vista assigns an integrity level to a user's token at logon. Recall from Chapter 2 that upon logon you get a token that contains

• Your SID

• The SIDs of any global and universal groups to which you belong

• Your privileges

As I briefly mentioned in Chapter 2, Vista also marks your token as medium or high (or, theoretically, anything else) by adding a kind of fake group SID along with your group SIDs to your token. But where many SIDs are long strings of numbers, an "integrity SID" looks like a simple

 S-1-16-value 

Where value is some arbitrary number. Look back to Table 4.1 and you'll see that value is 0 for the untrusted integrity level, 4096 for low integrity, 8192 for medium integrity, 12288 for high integrity, and 16384 for system integrity. But where did they get those numbers? Well, for those of us in the audience who've have had to do a lot of decimal-to-hex and back conversions, those numbers might ring a bell, because while 0, 4096, 8192, 12288, and 16384 may not look like they make much of a pattern, let's recast them in hex, where they become 0, 1000, 2000, 3000, and 4000-now, that makes some sense! And that all means that we're ready to actually see our integrity level.

Viewing User Integrity Levels

The Vista tool for seeing your current integrity level is the command-line utility whoami (which we met in Chapter 2, recall) either with the /group s or /all options. For example, if I'm logged onto a Vista computer and I start up an unelevated command prompt and then type

      whoami /groups /fo list 

Then among the output I'll get is this:

 Group Name: Mandatory Label\Medium Mandatory Level Type:       Unknown SID type SID:        S-1-16-8192 Attributes: Mandatory group, Enabled by default, Enabled group 

Notice that whoami calls this a "group" and refers to its name by a now-familiar one: "Mandatory Label\Medium Mandatory Level" which, we now know, is Vista's wordy way of saying "medium integrity level." Notice also the SID, 8192, which Table 4.1 told us is the one associated with a medium integrity level.

Give it a try yourself on a Vista box. Once you've seen the S-1-16-8192 SID, create an elevated command prompt and try it again to see the S-1-16-12288 prompt.

Process Integrity Levels

Given that Windows Integrity Control's Prime Directive is that no process can modify an object of higher integrity level, it's really the integrity levels of processes more than users that feature heavily in WIC, so let's take a look at process integrity levels.

How Processes Get Their Integrity Levels

Processes get their tokens by mixing two things that we've already learned in this book. First, recall from Chapter 2 that processes basically get their tokens from whomever started them; if Joe starts Word while he's logged in as a standard user with a medium integrity level, then Word will usually have a token with a medium integrity level. But remember that a process is nothing more than a copy of an EXE file running in memory, and that you've learned in this chapter that any file can have an integrity level embedded in it. When Vista starts a process, it uses this algorithm to decide what integrity level it gets.

• Rule 1: if someone with a high integrity level starts a process, the process runs with high integrity.

• Rule 2: if you start a process with "Run as administrator," the process runs with high integrity.

  If you're running as a standard user when you start a process, though, the rules change a bit.

• Rule 3: if you start a process while running as a standard user, then the process either gets an integrity level equal to the one on your token (medium), or on its EXE file, whichever is lower.

• Rule 4: it's always possible for one process to start another process at a lower integrity level, but for a process to start a process at a higher integrity level requires user approval through UAC.

Let's take a few examples to clarify this:

Example 1: Run as administrator Suppose I right-click the Notepad icon and choose "Run as administrator." The Consent UI appears and I choose Continue. Notepad is now running in high integrity mode.

Example 2: Started by an administrator Suppose I'm logged onto Vista as a member of the local Administrators group. I double-click the Notepad icon. What happens? Well, assuming that UAC is enabled, then I've got a split token, and unless I request elevation, then Notepad gets my standard user token. The actual notepad.exe file is unlabeled and therefore gets medium integrity level. As both the user token and the EXE file are of medium integrity, the process-Notepad-runs at medium integrity level.

Example 3: Started from an elevated command prompt I've started an elevated command prompt by right-clicking the Command Prompt icon and choosing "Run as administrator" and then Continue at the Consent UI. From that prompt, I type notepad and press Enter. What happens? Because I've started Notepad from the elevated command prompt, it inherits my S-1-16-12288 "high integrity" token. Rule 1 kicks in, so Notepad runs as high integrity.

Example 4: Starting a low integrity EXE file Suppose I've used icacls or chml to label an EXE file as low integrity. I'm running with a standard user token and I just double-click its icon-and do not start the EXE by right-clicking it and choosing "Run as administrator." Now Vista has a process to start that inherits a token at medium integrity, but whose EXE file is marked "low integrity." What happens? The program runs as low integrity.

We'll do some exercises that underscore this soon, but first let's get some more techie details out of the way.

Viewing Process Integrity Levels

Where does a process store its integrity level, and how can we see it? Well, a process clearly has an integrity level stored in its EXE file, but, as we saw earlier, that's only one factor in determining the integrity level that it ultimately gets, and, besides, a process can get quite different integrity levels at different times depending on who started it and how she started it, so clearly looking at the integrity label on the EXE is not the way to go.

Instead, a process stores its integrity level in its token, which can vary from run to run. To see a process's current integrity level, then, we need to peek into its token, which lives only in the computer's RAM.

Note 

That's unless, of course, the application is designed to read its own token and report to you on command. The only application that I know of that does that is whoami.exe.

You might think that integrity levels would be a perfect thing for Task Manager to show, but it doesn't, so we're on our own. Sucking up an application's token "on the wing" might make for some fancy programming, but thankfully we needn't, as Mark Russinovich has created Process Explorer, and you can find that at http://www.sysinternals.com. (Or at least you can now. By the time you read this, it'll probably be on Microsoft's site, as they bought Sysinternals. Too bad they didn't do it earlier-maybe they would have tossed Task Manager in Vista and replaced it with Process Explorer.) Start it with "Run as administrator" or it won't have the privileges that it needs to peek into other processes, and you'll see something like Figure 4.2.

Figure 4.2: Running Process Explorer on Vista

Well, actually, your copy of Process Explorer will look like that screen shot if you click View Select Columns, where you'll get the option to choose what you want Process Explorer to show you. I added two checks: "Integrity Level" and "Virtualized." (We're not going to use Virtualized in this chapter, but you may find it interesting if you read the last chapter. It tells whether or not a particular application will get the benefit of file and Registry virtualization.) Notice that this particular computer has processes running in low (Internet Explorer), medium, high, and system-level integrity levels.