Chapter 5: BitLocker-Solving the Laptop Security Problem

Dialing Up Custom Labels

For the last section in this chapter, I want to delve into a more advanced topic-low-level control of mandatory integrity levels. You've seen throughout this chapter that objects signify their integrity level through special access control entries called "mandatory labels." Knowing how to construct and apply a custom label lets you control not just integrity level, but whether folders will propagate their integrity level to their contents, what sort of restrictions they impose, and the like; with a knowledge of labels you can also remove mandatory labels altogether.

Meet SDDL Strings

When I say that we'll be directly manipulating mandatory integrity labels, I mean that we'll be using chml 's -wsddl: option to directly compose and write onto an object something called a Security Descriptor Definition Language (SDDL) string. To see what that means, here's a quick example. For example, if you were to type

 chml testfolder -wsddl:S:P(ML;CIOI;NWNR;;;HI) 

You would be telling Vista, "there's a folder on the system named ‘testfolder.’ Please find it and give it a mandatory integrity level of high. Also, tell the folder to ignore any attempts by lower-integrity processes to either write it or read it. Please ensure that any objects inside this folder get those instructions as well, but block any integrity labels from this folder's parent." Quite a bit for just "S:P(ML;CIOI;NWNR;;;HI)," eh?

That bunch of capital letters, colons, semicolons, and parentheses is a compact way of describing access control entries and access control lists is the SDDL string I referred to earlier. To crack that code, you've got to learn SDDL, and that's basically what we'll be doing in this section. The -wsddl option gets its name from what it does, as its job is to "write SDDL strings." With the -wsddl option, you can craft and apply SDDL strings to do anything that we've talked about in this chapter, and other things as well. (And icacls won't let you build your own SDDL string even though they finally fixed it!)

Understanding the Secret Language of Bs: SDDL Label Syntax

(That's "Bs" as in Orange Book Bs-mandatory access control systems. After all, without mandatory integrity labels, there's no building a mandatory access control system.)

When NT 3.1 came out, about the only thing that you could put permissions on were printers, files, folders, shares, and Registry keys, if memory serves. As time has gone on, Microsoft has added more and more "securable objects," places that will accommodate an access control list. But writing out all of the details of just a single access control entry can be a lengthy affair, particularly when you take into account the many kinds of permissions that a file or folder might offer, and when you consider all of the options for permission inheritance that popped up in Windows 2000. So Microsoft developed a shorthand method of describing an object's owner, its primary group (something you have probably never needed to worry about, nor will you likely ever worry about it in the future, as it's there for POSIX compatibility), its discretionary access control list, and its system access control list. We'll focus on that system access control list, as that's where the mandatory label lives.

A Windows Integrity Control label SACE, when written in SDDL, looks like

 S:sacl_flags(ML;ace flags;integrity control policy;;;integrity level or SID) 

For example, in the SDDL string S:AI(ML;CIOI;NR;;LW) the SACL flag is AI, the ACE flags are CIOI, the Windows Integrity Control policy is NR, and the integrity level is LW. To see how to decode all of that, we'll consider each piece in detail.

Warning 

Remember, SDDL strings all use capital letters. Using lowercase letters in SDDL strings will, in my experience, always fail.

The SACL Designator

The first part of the SDDL string, S:, means "the information following is a SACL." More complete SDDL strings can have designators O:, which precede the object's owner, or G:, which precedes the object's primary group, or D:, which precedes the object's DACL. The SACL S: designator does not vary, and must always be capitalized. There is only one SACL per object, although Vista's programming interfaces differentiate between SACEs that are just auditing entries and those that are mandatory labels. That's why running chml filename -sddl yields only the mandatory label SACE, and no audit SACEs.

The SACL Flags

SACLs and DACLs changed significantly with the advent of Windows 2000 because of inheritance. You can, however, tell any object to ignore any inherited ACEs and to only use explicitly defined ACEs. Take a look at Figure 4.10 and you'll see what I mean.

Figure 4.10: A typical DACL

This is a discretionary ACL rather than a system ACL, but I chose it because it's a bit more "complete," which helps illustrate what I'm trying to explain. First, a reminder about ACEs and the ACL: this is one ACL, and it contains four ACEs. It is the ACL on an object, the file test.txt. And now the important point: notice the check box in the lower left-hand corner, the one labeled "Include inheritable permissions from this object's parent." Unchecking this would cause all of this object's DACEs to go away, because as you can see by the "Inherited From" column, they are all inherited.

The SDDL way of saying, "uncheck the ‘Include the inheritable permissions from the object's parent,’" is to add a SACL flag of P, which is short for "protect this object from inherited SACEs" according to Microsoft documentation. So, for example, if I were to put a SACL like S:P(ML;;NR;;;LW) on a file, I'd be saying, "here's a SACL for you, and ignore any SACEs from your parent."

Note 

Remember that here, "parent" means the folder that the file lives in. Recall that a files or subfolders inside of a folder are said to be "child objects."

There are two other possible SACL flags: AI and AR, although you'll probably never, ever see AR. P is easy to understand because it corresponds exactly to that check box in the user interface, but there's nothing in the user interface that corresponds with AI or AR.

Recall that by default most child objects-files and subfolders-inherit the DACEs and SACEs on their parent object, the folder that they live in. But how do those DACEs and SACEs actually get copied-"propagated" is the term people use in inheritance talk-to the child objects? I mean, it's not like you've got to remember to push a "refresh permissions" button whenever you change a folder's DACL or SACL, and yet the children inherit whatever new thing you did to the parent, so how does that happen? There is a background routine in Windows that watches for changes in permissions on a folder and, when that happens, it springs into action and propagates the new DACEs and SACEs to child objects. That, in turn, may trigger propagating them to "grandchild objects" so long as those grandchild objects aren't blocking inheritance. That can go to "great-grandchild objects" and so on. On a big system with a complex folder structure and a slow CPU and disk, this might take a while. (I've never seen it, but it's possible.)

To keep track of which ACEs have been completely propagated and which are still in the process of being completely propagated, Windows automatically puts a flag on any changed ACLs, an AR flag that basically says, "Windows, I'm a modified ACL, can you come propagate me to my child objects?" AR is a flag put on an ACL by Windows, for Windows. Once Windows has completed propagating an ACL to its child objects, then Windows resets the AR flag to AI. That's why you will find an AI flag on many objects' SACLs; it just means that the object's SACL includes one or more inherited SACEs, and that Windows has completed propagating those SACEs.

You can see this by opening up an elevated command prompt and navigating to C:\mystuff. Then create a new folder C:\mystuff\testfolder and give it a high integrity level. By default, chml creates folder permissions that propagate to child objects. Then create a file inside testfolder called test.txt, and examine its SDDL; you will see the S:AI flags. You can do that with these commands:

 md testfolder chml testfolder -i:h -b createfile testfolder\test.txt chml testfolder\test.txt -sddl -b 

You'll get a response of

 SDDL string for testfolder\test.txt's integrity label=S:AI(ML;ID;NW;;;HI) 

Reviewing, then, on any given SACL you may see no flags, or you may see P if you've blocked inheritance on an object. In addition to P you may see AI and in theory AR, but I doubt it.

The SACE Type

With the SACL designator and SACL flags out of the way, it's time to explore the SACL's one and only security access control entry. In SDDL-ese, ACEs-both discretionary and system-are set off by parentheses. The next character in the SDDL string, then, is a left parenthesis.

The SACE has six parts, four of which we will use: the SACE type, its inheritance flags, the integrity level policy, a couple of parts only relevant to Active Directory objects, and the integrity level. We'll take them in turn.

The first item in a SACE is the "SACE type." For years, auditing SACEs mainly came in a few varieties: "audit" SACEs, "object audit" SACEs, "object alarm" SACEs, and "alarm" SACEs. (I can't say that I've ever used one of the alarm SACEs.) Windows Integrity Controls brought a new kind, a "mandatory label" type of SACE. SDDL designates SACE types with one- or two-letter abbreviations, and ML is the one for mandatory labels. Hence, every integrity label has the same SACE type, and thus they all start out (ML.

SACE Flags

Just as a SACL could have flags, so also can each SACE in the SACL. You may see no flags on a mandatory label, or you might see some combination of these five, which I'm identifying by their two-letter SDDL abbreviations:

• CI, or "container inherit"

• OI, or "object inherit"

• NP, or "inherit but do not propagate"

• ID, which indicates that this is an inherited SACE

• IO, or "inherit only"

  Whether or not you realize it, you've probably bumped up against these flags before. Take a look at Figure 4.11 to see what I mean.

Figure 4.11: Standard "create a new ACE" dialog box with "apply to" options visible

Figure 4.11 shows you the dialog box that you'll see if you ever want to create a fine-tuned permission on a folder. Clearly it's a discretionary ACL rather than a system ACL, but the dialogs work the same. The drop-down list box labeled "Apply to:" might be better labeled "Inheritance instructions." There are seven of them, and one more important control on that dialog box-the "Apply these permissions to objects and/or containers within this container only" check box. You'll see that each of those eight functions corresponds to different combinations of the five SACE flags.

No Flags: "Apply It to Me"

A SACE with no flags applied to a folder cannot be inherited, so no files or subfolders in that folder will get the SACE. The folder itself will get the SACE, however. The "no flags" scenario usually makes more sense on files than it does on folders, as files can't have child objects. (In fact, most of the SACE flags don't make sense on files for that same reason-they can't have child objects.) In short, by default a SACE applies to the object that it was applied to. It's only when you start adding flags that things change from that simple default behavior.

CI: "Copy This to the Subfolders"

A CI, "Container Inherit," flag tells Windows not only apply this SACE to this object, but also to propagate this to any containers inside this object. So, for example, suppose you applied a low mandatory label's SACE with the CI flag to a folder named C:\folder1. Any folders inside C:\folder1 would inherit a low mandatory label, as would any folders inside them. But any files in C:\folder1 would not inherit a label of any kind. CI wouldn't make sense on a file because it has no child objects to propagate to.

OI: "Copy This to the Files"

OI, "Object Inherit," works like CI, except instead of restricting inheritance to folders, it restricts it to files. When you create a file, the default inheritance in Windows is CIOI, so that both files and subfolders in a folder inherit that folder's permissions. OI wouldn't make sense on a file because it has no child objects to propagate to.

IO: "I Don't Want it, But the Kids Can Have It If They Want"

IO, "Inherit Only," tells Windows, "I've applied this SACE to such-and-such folder, but don't apply its effect to that folder." I know that doesn't sound like it makes sense, and in truth it doesn't make sense if it were the only flag on a SACE. But now consider a combination of CI, OI, and IO. CI and OI say, "let my child subfolders and files inherit this SACE," and IO says, "…but don't apply it to me." IO wouldn't make sense on a file because it would basically be saying, "don't apply this SACE to me," and inasmuch as files don't have child objects, then there would be no one else to apply it to, which would essentially nullify the SACE.

NP: "Okay, the Kids Get It, but Not the Grandkids"

The NP, "inherit but do not propagate," flag lets the SACE propagate to the subfolders and files inside a folder, but no further: the grandkids get left out. If you check that box in the Permissions dialog that says, "Apply these permissions to objects and/or containers within this container only," then you'll get an NP flag on your SACE.

ID: "I Didn't Start This, I Only Inherited It"

Unlike some other operating systems, Windows propagates inherited ACEs by physically copying them to child objects. Thus, Windows objects may have ACEs that have either been explicitly applied to them, or ACEs that they got when the inheritance process caused Windows to just copy an ACE from a parent. An ID flag in a SACE shows that the object inherited the SACE.

All of that enables us to see how each of the settings in the drop-down list box back in Figure 4.11 work out:

• "This folder only" says to apply the permissions to the folder object, and nothing else. That means no inheritance, which means no flags.

• "This folder, subfolders, and files" means to apply it to the folder object (the default behavior) but then to also propagate it to any subfolders or files in the folder. CI propagates to folders, OI to files, so the flags would be CIOI. (Or OICI.)

• "Subfolders and files only"-my italics and yes, I know I'm doing this out of order, but I wanted to contrast it with the previous setting-clearly indicates that CIOI is called for, but what's that "only" mean? It means "…but don't apply that SACE to me, the parent folder." To satisfy that need, we add IO, "Inherit Only," for a set of flags equaling CIOIIO.

• "This folder and files" means "this folder" which, we've seen, is the default behavior and calls for no flags, and "files" means OI. The SACE flag for this situation is, then, just OI. Notice that it didn't mention subfolders, so no CI.

• "This folder and subfolders" is the reverse situation: subfolders but no files. Subfolders are containers, so CI is sufficient here.

• "Files only" calls for OI, and "only" calls for IO, so the flags are OIIO.

• "Subfolders only," similarly, is CIIO.

The example output that I offered before, with the SDDL of S:AI(ML;ID;NW;;;HI), has a flag of ID, meaning that it has no inheritance settings, and that test.txt got it through inheritance. Had the SDDL lacked any flags, it would have looked like S:AI(ML;ID;NW;;;HI).

SACE Rights

Thus far, we've seen the type of this SACE-a mandatory integrity label-and its inheritance flags. Next, we see what sort of integrity policy it requires. Recall that Windows Integrity Controls let us opt to block attempts by lower-integrity processes to read, or write, or execute a higher-integrity object. SDDL strings represent that with these flags:

• NR = do not accept read requests from lower-integrity processes.

• NW = do not accept write requests from lower-integrity processes.

• NX = do not accept attempts by lower-integrity processes to execute this object.

A mandatory integrity SACE must have at least one of these, and can have all three. So, for example, all of these SACEs are legal:

• S:(ML;CIOI;NW;;;HI) would just block writes.

• S:(ML;CIOI;NRNW;;;HI) would block reads and writes.

• S:(ML;CIOI;NWNRNX;;;HI) would block reads, writes, and executes.

Once you've installed your integrity policies in your integrity SACE, then add three semicolons, as these kinds of SACEs don't need the next two fields. We're just about done!

SACE Trustee: The Integrity Level

ACEs usually refer to an account that's getting granted or denied some kind of access. The user account or group that's referred to in an ACE is called the "trustee" in Microsoft security-speak. Mandatory integrity labels include a SID, but it's one of a few predefined SIDs that convey an integrity level, the SIDs that we saw back in Table 4.1. Thus, to build a mandatory integrity label SACE that applied to a file and thus didn't need any inheritance rules with a policy that denied executes and marked the file as high integrity, we can look up "high integrity" back in Table 4.1 to get the S-1-16-12288 SID, and build our integrity SDDL string like so:

 S:(ML;;NX;;;S-1-16-12288) 

Reviewing, this is a SACE with no SACL flags, is a mandatory integrity label (ML), has no SACE flags because of the ;; after the ML, enforces a "no execute" policy because of the NX, then we skip two fields and end up with the high integrity SID. That works great, but those SIDs are a pain to type, so Microsoft has predefined abbreviations LW, ME, HI, and SI for low, medium, high, and system integrity levels. With that in mind, we can shorten up the above SDDL string without changing its effect:

 S:(ML;;NX;;;HI) 

Using SDDL Strings to Set Integrity Levels

Once you've got an SDDL string, you feed it to chml with the -wsddl: option. To apply the above SDDL string to a folder called C:\noex, you'd type

 chml c:\noex -wsddl:S:(ML;;NX;;;HI) 

You can also examine the SDDL string of an existing file or folder by using the -sddl option, as in

 chml c:\noex -sddl 

You will find that most files and folders lack an SDDL string altogether, or perhaps they have an empty SACL inherited from somewhere, as when chml reports an SDDL of S: or S:AI. That's SDDL-ese for a SACL without a SACE, or an empty SACL. And that's handy to know because I don't know of any Microsoft tools for removing a mandatory integrity label. Do it with chml like so:

 chml c:\noex -wsddl:S: 

What else could you do with the ability to handcraft SDDL strings? Well, the options on chml assume that if you want to label a folder, then you want its label to propagate to its child objects. If you don't want the label to propagate at all, then you can add the -noinherit flag. But what if you wanted to give a folder C:\documents a medium mandatory label that protects reads and only have its direct children inherit that label? There's no way from the chml options, but you could build an SDDL string to do it, as in

 chml c:\documents -wsddl:S:(ML;CIOINP;NR;;;ME)