A Note on Modifying System Files

Using WIC ACEs to Restrict Access

We've already seen a couple of examples of how Windows Integrity Controls can restrict a program from modifying or deleting a file. That's WIC's default behavior, but that's not all that Windows Integrity Controls can restrict. They can also stop a lower-integrity process from reading a higher-integrity object, or, if the object is an EXE or related file, WIC can stop a lower-integrity process from executing the program in that file.

I've already told you that to protect a file or a folder from lower-integrity processes reading that file or folder, you just have to add a special kind of ACE that is recognized by the operating system as a mandatory label to the file or folder that says, "this is an object of such-and-such integrity level," and that that's how WIC protects objects from being written. But I've not told you the entire story because in actual fact there is no kind of ACE that merely declares an object's integrity level; instead, the ACE says "this object has integrity level such-and-such," yes, but the ACEs that we've applied so far also say something like "and it does not wish to be written by lower-integrity items." There is room on that ACE for you to add that the object should not be read from, or executed.

chml lets you do this with the -nr, -nx, and -nw options. "NR," "NW" and "NX" are, as you've probably guessed, Microsoft's shorthand designation for the restrictions on reading, writing, and executing, respectively. For example, to give a file named test.txt a high integrity level and to tell the operating system not to let lower-integrity processes read the file, just type

 chml test.txt -i:h -nr -b 

Note 

icacls does not have the ability to create NX or NR WIC policies; it can only create NW entries.

Thus far you've not had to worry about including -nr, -nw, or -nx because I wrote chml to assume an NW option whenever none of the three were specified. The internal structure of the mandatory integrity ACE leaves room for all three of the options, so you could even lock test.txt right up with

 chml test.txt -i:h -nr -nx -nw -b 

(It doesn't matter what order you specify the -nr, -nx, or -nw options; just be sure that the first option is the file or folder's name.) You can see this in action with just a few commands. As before, start up two command prompts, one elevated and one not, and navigate to C:\mystuff in both. Then, from the elevated command prompt, type these lines:

 createfile a.txt chml a.txt -i:h -nr -nx -nw -b 

Then, from the nonelevated command prompt, type type a.txt. You'll get an access is denied message.

Where could you use this? Well, if you really wanted to tighten up the protection from the Internet that Windows Integrity Control seems to have been designed for, then you could set an NR ACE on your entire C: drive and make exceptions for the few built-in low integrity folders.

Warning 

That, by the way, is just a thought; I've not had time to test it, so please don't do it without testing it thoroughly first!

Note 

Along those lines, this is one area of WIC that honestly disturbs me a bit. What if a bad guy were to install some malware on your system and then figured out how to set all of the files, folders, and Registry keys relevant to the mal-ware to system integrity? My guess-I'm not a good enough programmer to get this to work yet-is that because I notice that system services run in system integrity level, then there may be a way to write a service that can manipulate integrity levels all of the way up to system. Time will tell.