|
From: <JB...@Da...> - 2003-11-27 12:12:13
|
Some open questions in your ntfs docs are documented by MS! (or at least obvious from knowing their style) Specifically: Why do some Metadata files on NTFS 3.0+ still have Security Descriptors? On NTFS 3.0+, $Volume, $AttrDef, dot and $Boot have Security Descriptors. Is this to save time at boot up? Perhaps to reduce the number of files it has to parse? Or is this the same as the previous question? My Guess: To make sure older Microsoft NTFS drivers do not allow insecure access to these critical files. Remember: No security descriptor = all access for everyone = UNIX mode 777 Attribute Header When is "Initialized" not the same size as "Real"? This is documented in connection with a new XP IOCTL to change it directly. The short summary: The bytes from 0 to real -1 are the current file data The bytes from Initialized to allocated -1 have not been initialized securely and may contain bytes that used to be in entirely different files that were not readable by those who can read the current file. C2 level security (and basic security thinking) require that such bytes not be revealed to applications that simply use documented file I/O calls (such as seek() past end then write bytes there) do not suddenly see those bytes as part of an area in their file which they have allowed to contain old garbage in that way. So if an application tries to set Real > Initialized without writing to every byte in between, NTFS.SYS makes sure the old contents of those clusters is overwritten with zeroes or other nonsecret garbage The bytes from real to Initialized - 1 have already been cleared by NTFS.SYS or contains bytes that used to be part of this file itself. If the use tries to increase the value of Real, NTFS.SYS makes no attempt to clear the contents of these bytes. Security Descriptors How are ACEs inherited? The full format, layout and inheritance of Security Descriptors, including ACEs, Sids etc. is a generic NT mechanism not at all specific to NTFS. NT even exposes user mode functions to dream up your own kind of data, including your own way of storing SDs within that data, and then call the NT functions that manipulate ACLs, ACEs etc. Officially, the entire SD format is opaque and you should access it only through the (complete) set of manipulation functions available in ADVAPI32.DLL. In practice, because SDs can be legitimately stored on disk, in databases, in your own dreamed up kind of data etc., the format is carved in stone. The actual data format (more complete than your description) is described by comments in winnt.h in the Microsoft Platform SDK headers. The inheritance rules are in the SDK. There are two VERSIONS of the inheritance rules: The classic, pre-Windows 2000 rules are used when NTFS is accessed from NT 4.0 or older, no matter what the NTFS version. The new, Windows 2000 and later rules are used when NTFS is accessed from Windows 2000, no matter what the NTFS version. The New rules simply add the various "autoinherit" bits in the SD, ACL and ACE headers, these bits were 0 in NT 4.0 created SDs and 0 means NT 4.0 semantics, while each 1 bit enables a new feature. If a Windows 2000 created SD happens to have all the autoinherit bits turned off by the user (not uncommon) it is binary identical to an NT 4.0 originated SD. If NT 4 accesses an SD with some of these bits set, it will ignore those bits, and the specific semantics are designed so the read-only semantics are still correct, and the write semantics are ok if the write clears the bits. There is a 3 part article series on MSDN named "the guts of security" which is a great intro to the NT 4.0 rules. |
