Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

A recent challenge in debugging a software configuration problem for a customer led us to suspect that the new Windows Resource Protection (WRP) feature in Vista was thwarting their efforts to change a system registry key. This turned out not to be the cause of the problem … but it afforded us an opportunity to learn about some new APIs.

What is WRP? Some info is here - http://msdn2.microsoft.com/en-us/library/aa382551.aspx. In summary, it’s a feature that restricts access to certain parts of the file system and system registry, such that the "NT SERVICE\TrustedInstaller" SID is required in order to make any modifications. For example,

>cacls c:\Windows\System32\ntdll.dll

c:\Windows\System32\ntdll.dll NT SERVICE\TrustedInstaller:F

BUILTIN\Administrators:R

NT AUTHORITY\SYSTEM:R

BUILTIN\Users:R

Two new APIs are available in Vista to locate protected resources (although checking the ACL for Owner = TrustedInstaller is another sure sign): SfcIsKeyProtected and SfcIsFileProtected. I decided to write a little program that takes either a reg or file path, calls the appropriate SfcIs*Protected API, and reports the result.

Two confusing things I discovered about using the new APIs:

  • The documentation for SfcIsKeyProtected (http://msdn2.microsoft.com/en-us/library/aa382537.aspx, as well as the Vista RTM SDK download version) is wrong, in that the reported behavior for an un-protected key is to return FALSE and SetLastError of ERROR_FILE_NOT_FOUND. In fact, GetLastError is ERROR_SUCCESS in that case (on my x86 Vista RTM machine), which I think makes more sense anyway (see next bullet).
  • The documentation for SfcIsFileProtected also states that the behavior for an un-protected object is to return FALSE and SetLastError of ERROR_FILE_NOT_FOUND. In this case, that happens to be the observed behavior! Only problem - that makes the API harder to use, especially as a debugging assistant based on user input. Namely - how do you know the difference between the two conditions: file-not-found vs file-found but not protected? One possible answer: you have to also use CreateFile to verify that you didn’t mistype. Additionally painful is that you’ll want to call CreateFile in such a way as to minimize the chance of misleading error conditions (e.g. the file exists but you don’t have access; the file is already opened exclusively; etc).

Anyway, that’s the approach I took. An alternative would be to avoid the Sfc calls altogether and use RegGetKeySecurity/GetSecurityInfo. The benefit with the latter approach would be that it could probably be done entirely in managed code.

Permalink |

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment