NULL DACL Behaviour in Windows Vista
Subtitled: Don't believe everything you hear at TechEd.
I was inspired by my "empty DACL" issue, and what I remembered of Jesper's "Is That Application Really Secure?" talk from last June's Microsoft Tech-Ed conference, to test whether my security issue was caused by a NULL or empty DACL.
Jesper had said in his talk that Vista changes the behaviour of NULL and empty DACLs - that NULL DACLs were changed to mean "no access", from Windows XP's behaviour of "full control to everyone"; and that empty DACLS are changed to mean "no access", from XP's "full control to owner; no access to everyone else".
Note, however, what ICACLS, Vista's replacement for CACLS and XCACLS says on files that I create and assign restrictions to:
empty.txt No permissions are set. All users have full control.
null.txt No permissions are set. All users have full control.
Successfully processed 2 files; Failed processing 0 files
As you can see, ICACLS says that both an empty DACL and a NULL DACL mean "everyone, full control". Here's what Explorer properties says about them each:
So, ICACLS disagrees with Explorer, and they both disagree with Jesper.
Although Jesper's the most reliable source I know, he was of course talking about Beta software that was not yet tied down, so it's entirely possible that what was true in the Beta version of Vista last June (or was planned to be true by release time) got changed before the product could actually make it to market.
The best thing to do, then, is to test.
Sure enough, I can write to the NULL DACL file from any account, and I can't write to the empty DACL file from any account - including the owner of the file.
So, Explorer's right, this time around. NULL DACL means "full access to anyone, including the guest", and an empty DACL means "no access to anyone, including the owner".
I discussed this with Jesper, who noted that he was passing on statements from other team members about functional changes that obviously didn't make it in to the final cut for Vista - whether for time reasons, or because the changes were ruled inappropriate (maybe backwards compatibility got in the way?).
This demonstrates that you absolutely need to not only understand the documentation for the behaviour of various DACL settings, but that you also need to test, test, and test again on all the platforms you support.
Null DACLS, then, are still a phenomenally bad idea, and you just plain shouldn't use SetNamedSecurityInfo if you don't know what you're doing!