Acces denied for Admins?

[CharlotteTheHarlot]

Actually I wasn't clear. I knew about 2K/XP on FAT32, but just never felt like trying because of the inevitable disk limitations, and the lesser integrity from non-journaling and other safety valves.

What I meant was some way to create an NTFS system without $Secure, and to further the daydreaming - some way to eliminate streams also ( streams I am just biased against because of the concept of hiding stuff from the computer owner. )

The thing about ACL's is they are implemented in all-or-none fashion. I think a better idea would have been starting with a fresh naked NTFS space, no ACL's on any object, and only then adding them in for specific objects when wanted. Windows API should have used functions that first test for presence of ACL on an object and then efficiently fall through when absent, and only cycling through security procedures when they do exist. Unfortunate design choices in the early NT era I guess, because if in Windows functions ACL's are assumed to exist everywhere there is little to be gained by removing $secure from NTFS because Windows itself will still be doing the work as if they were there.

Presently we have the worst possible implementation IMHO, access control lists for every object ( file/folder/key ) and they must be consulted for every transaction, and of course are available to be tampered with by everyone at will, and there is no comprehensive tool to manage the chaos. However, ACL's created à la carte ( i.e., objects are clean by default, permissions only exist when intentionally specified ) would mean you could pull up a list of all ACL's ( maybe only existing for 1% of all objects ) and the entire thing would be manageable, and changes such as modifications or new or deleted permissions could be identified easily. The event log could perhaps be used to show the history of such creations/deletions/changes as well. It's just such a mess now.

Bonus philosophical question of the day: was SETACL a godsend or a thorn in our side. ( NB: it came along in the WinXP transition era, but in the years since most of the same functionality has been added to setup applications like INNO etc. When you create a setup.exe these days it's as simple as a checkbox or added parameter to specify permissions on not only the distribution files, but anything on the target system. In fact it's really a simple matter to whip up a "permissions fixer" standalone EXE that corrects/creates problems on a system. )

[jaclaz]

Yep , but I doubt that "plain" filesystem journaling represents an effective "safety measure" (when such a number of programs and services run in the background).

Having a transactional filesystem may possibly help (due to the "atomic" nature of the transaction log) and not-so-casually transactional NTFS was introduced with Vista

But (just for the record), at application level, the thingy was rather poorly implemented, or documented, or both , to the point that it is now "deprecated" :

http://msdn.microsoft.com/en-us/library/windows/desktop/hh802690(v=vs.85).aspx

TxF was introduced with Windows Vista as a means to introduce atomic file transactions to Windows. It allows for Windows developers to have transactional atomicity for file operations in transactions with a single file, in transactions involving multiple files, and in transactions spanning multiple sources – such as the Registry (through TxR), and databases (such as SQL). While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.

The good MS guys, however seemingly "invented" a transactional exFAT for Windows Ce/Phone, TexFAT (of which exist seemingly also a 2.x version, completely UNdocumented) see:

http://www.forensicfocus.com/Forums/viewtopic/t=11393/

http://www.forensicfocus.com/Forums/viewtopic/p=6571453/#6571453

That filesystem may be (if ever it will be available/usable on "real" Windows PC's) a good "no permission/no unneeded fluff" kind of solution.

But of course this - even if it will ever happen - won't change in any way the situation of the Registry which is in itself a filesystem (and actually very similar to NTFS) if you look at it from the right angle :

http://reboot.pro/topic/7681-the-registry-as-a-filesystem/

A nice experiment (if anyone has time/will) would be to try making a Windows 7 "standard" install (the one with the 100 Mb stupid "boot" partition - which the good MS guys call "system" - and a second "system" partition - the one which the good MS guys call "boot").

Then replace the second partition with a "copy of it" but formatted with a UDF (or exFAT or TexFAT) filesystem.

Will it work? (i.e. has the BOOTMGR the capability to access UDF (or exFAT or TexFAT) filesystems?)

jaclaz

P.S:: IN the mentioned thread on reboot.pro:

http://reboot.pro/topic/19643-winsxs-hardlinked-files/

another member posted his experience with manifest files that can be removed from the WinSXS directory safely, so even 7 is possible.

If you want to do do the test, remember that the 7 installation footprint on disk will grow to 9 Gb or more, almost 10 Gb if I recall correctly.

Edited April 4, 2014 by jaclaz