https://rwmj.wordpress.com/2010/02/18/why-the-windows-regist...
Actually you can use the Windows Projected File System to project the registry into the file system, making registry keys and values appear as files and directories.
https://github.com/Microsoft/Windows-classic-samples/tree/ma...
Like for example, you already point out how the type system in the registry is very limited. But isn't the filesystem even worse? Everything there is binary blobs with no types at all. So how does that improve things?
It seems like your complains don't really have to do with the "directory" structure of the registry much, so I don't think moving to a file based model would really change anything. You'd just end up with the same legacy issues, but spread across more files.
Finally, AppData wasn't introduced with Vista, but rather it's always been there if applications need to store file-based data rather than individual configuration values. That is not a new or improved way of doing things as you seem to imply in the post.
NTFS specifically has file forks ("Alternate Data Streams") and I guess you could use those to store a type, although whether using forks would be a good idea or not is up for debate.
how does this amaze anyone? how do people think backwards compatibility works?
Microsoft, supporting Windows, promises to make every effort to maintain backwards compatibility wherever possible so that programs compiled for, say, Windows 95 will run unmodified on Windows 10.
Not every program from 20+ years ago runs, but a lot do! That's a very hard thing to do if you wish to continue to advance the technology you use in your operating system. Apple doesn't even try.
Microsoft have taken steps to break backwards compatibility a few times in the name of progress and every time I talk to people during those transition periods, it is a 50/50 split between people who don't know that they've been given a decade of notice and now their "tried & true" software development paradigm doesn't work anymore, and people who are angry because most of the old ways are still supported.
The registry wasn't even supposed to be what it is today. it was a small stop-gap thing to stand in place while a better solution was developed. Developers discovered it, started using it, and now Microsoft has to support it. Of course it's rubbish; metaphorically, it's a piece of a whiteboard used as a doorstop until the real doorstop is delivered, except for some reason people started using it for important stuff and now everyone needs it.
That doesn't have anything with backwards compatibility. Nothing forces MS to stick to old ad-hoc memory dump format. Neither there is anything that would suggest registry is deprecated, new Windows components keep using it and adding piles of junk into it.
Most of the actual technical issues you list have more to do with it being extended for the last 30 years in a backwards compatible way than anything to do with it being a hierarchical db instead of a filesystem.
http://reboot.pro/topic/7681-the-registry-as-a-filesystem/
https://web.archive.org/web/20090413131629/http://czwsoft.dy...
https://web.archive.org/web/20140401212651/http://pasotech.a...
And:
Also, they would have been able to at least improve the on-disk format with a major version; I highly doubt that the registry itself is backwards-compatible anyway and there are probably very few programs that access it directly.
A filesystem solves these issues specifically because it avoids reimplementation. As the registry has been extended as you say it approaches parity with filesystem functionality, but on a parallel track.
At a high level, avoiding multiple implementations of similar metaphors is ideal in terms of security. Reuse what you have.
There's nothing that has to be backwards compatible in registry internal storage format, they could just design new sane format and keep old API.
A better solution would be a simple database (like sqlite3) but then the immediate counter-argument is "okay, so we're done: it's already a simple database", because the registry hive is literally a file-backed database in the same vein as sqlite =)
You're right that a file per value would take a whole block on disk given the way some filesystems are currently implemented, but that's not an immutable feature of all filesystems - some Unix filesystems store small files in the inode. A real database is possible, but also the registry must be available very early in Windows boot (actually it's used by the bootloader, but also by the critical device database) so you'd want something that's at least easy to read with a smallish amount of code.
Also the Windows Filesystem driver stack is not very efficient for accessing many small files. It's built for flexibility and security, not speed.
The importance of using a filesystem interface is reuse of the access control mechanisms and filesystem API. It would avoid the type of bug above, due to nesting a hierarchical permissioned structure inside a file.
Current machines aren't the ones as Windows 98 with 32MB of RAM requiring binary configs for the OS everywhere.
I'll take all the side-channels I can get though. These "exploits" are really useful for regaining control over my own PC.
Just yesterday I learned how to Run-As TrustedInstaller, and that let me remove a lot of unwanted bullshit on my windows 10 install.
Not really? What does this exploit let you do that you couldn't already do with a local administrator account? Or are you making the general argument that "EoP exploits are features because they allow you to jailbreak your device"?
>Just yesterday I learned how to Run-As TrustedInstaller, and that let me remove a lot of unwanted bullshit on my windows 10 install.
They're not really comparable. You need admin to do it, which means you already crossed the security boundary[1]. This is in contrast to this exploit which allows you to cross a security boundary.
[1] https://devblogs.microsoft.com/oldnewthing/20121207-00/?p=58...
There are some things that users in Administrators group still can't do. Hence the need for TrustedInstaller perms.
For example, try running this script:
https://github.com/W4RH4WK/Debloat-Windows-10/blob/master/sc...
You will get access denied since few months back:
I understand Linux, Mac, FreeBSD, Magic-Pony-OS is not everyone's cup of tea or they might not be in a position to choose their OS (Work etc)
But DAMN that quote above is really showing me how bad it is out there ! Sure it can/does happen on other OS as well, but I'm betting Windows is the leader in "my-pc-is-not-my-pc-anymore" :/
I could even see the path for getting our product off the Windows platform and onto Linux (while still using Microsoft's dotnet toolchain). There are only 2 DLLs keeping us locked to Windows and I have a very solid hypothetical answer for both.
All of this is so depressing because it doesn't have to be this way. A few small changes to the OS (that would incur negligible impact to Microsoft's cashflow or margins) could mean life changing improvements in the user experience.
If profit must be obtained, then Microsoft should consider a "hacker" build of windows that starts as a bare-ass powershell prompt that you have to tack on what you want to use. I'd pay a fucking premium. Microsoft, are you out there? Charge me $1000. I swear I'll pay it if you promise to not shove updates, telemetry, defender or cortana down my throat ever again.
There are PCs out there running ChromeOS and Android. Not to mention smartphones and game consoles.
Windows is not good in this regard, but it's by far not the worst (though the UX for administrative actions is really not great, IMO).
Just because they took a part of the system that used to be externally facing and made it internally facing, I don't think that is the same as making "your PC not your PC anymore". If they were blocking administrators from executing arbitrary code or having arbitrary access to I/Os, that would be a different story.
Actually Windows is quite awesome nowdays. I was using mentioned OSes for years during periods of Windows downs, and since Satya Nadella took the leadership I was very happy with Windows (I primarily spend my time in PowerShell, browser, vscode and using dev tools but have different dedicated installations for games, media etc.)
Now with this can't-turn-off-helicopter attitude I am really considering switching to some Linux variant again. Mac is totally out of question due to similar concerns.
and there I was thinking you were joking, but there's actually a PonyOS!
Luckily all the tools I use on Windows are x-platform and with PowerShell, vscode, sql server etc. on linux and games working nothing holds me any more. I will probably miss Autohotkey and Foobar2k (maybe total commander but Dobulecmd is decent alternative and much better in some domains).
Windows 10 was what broke me and got me to using Linux full time. Before that, I barely knew how to even just get my way through debian to resume a disconnected screen session. Now I prefer to be in Linux. Even if the software that I can run using Wine/PlayOnLinux/Proton/Lutris isn't 100%... it's sufficient to where I don't miss being on Windows at all.
I recently upgraded my main system and used the extra parts to rebuild my Win 10 standby box. I grew up on Windows. Started with Win3.0/DOS and used every iteration except WinME and Vista... and the rebuild only reminded me how much of a pain in the ass Windows is to install. 10 still has a lot of the usability bugs I've encountered from way back in the Win98 days but all the extra crap we have to deal with now (most inconsistent and overencumbered UI ever) just makes it even more of a chore to use than it ever has been.
For what it's worth, Foobar2K runs great in Wine.
Why not just disable it using group policy?
shadow copies are automatically created as part of system protection (enabled by default).
Not a big deal for a single user machine — there’s nothing you can do with this that you can’t do some other way as a local admin/root — but not good if you have untrusted, non-admin user accounts.
Which makes you wonder really how comfy OSX POSIX is, but they had their own fun bugs lately too, sudo for example and other ones. Plus they're doing an CPU Arch jump.
Kinda feels like the 90's again, in a sense.
I used to open these sites incognito or delete the cookies manually but it's really such an annoyance. Better to automate the policy of disallowing these folks to store cookies.
If the few that do care still visits there is no incitement for the site to not do it.
It does leave me more likely to skip content I find on medium - this particular blog has the type of content that would make it a rare exception.
Extents and Rawcopy were initially written several years ago:
http://reboot.pro/files/file/316-extents/
https://github.com/jschicht/RawCopy
Or is there something new specific to Windows 10?
Seems that MS just released articles on how to prevent it but no update/patch.
Perhaps it's hard to fix, i.e., too many things on windows rely on it?
This is security 101. AFAIK, you can login as a local admin since forever and it’s never been fixed. I just used it recently to access a deceased relative’s computer.
Of course in reality installing any untrusted software on a computer that's not airgapped from everything you care about isn't safe. But that doesn't mean we shouldn't at least try to give better security guarantees.
There is nothing more common than running untrusted software.
This kind of attitude is completely useless.
I could then read all the user's documents.
I thought the point of disk encryption and secure boot was to prevent that. Yet somehow the hole of allowing Windows setup to give you a privileged command prompt with a decrypted disk was never closed...
Some Windows configuration have bad permissions on their SAM database. If a standard user has access to shadow copies (VSS), this can lead to privilege escalation.
Microsoft recommends to [1]:
1) Restrict access to the contents of %windir%\system32\config: - Command Prompt (Run as administrator): icacls %windir%\system32\config*.* /inheritance:e - Windows PowerShell (Run as administrator): icacls $env:windir\system32\config*.* /inheritance:e
2) Delete Volume Shadow Copy Service (VSS) shadow copies: - Delete any System Restore points and Shadow volumes that existed prior to restricting access to %windir%\system32\config. - Create a new System Restore point (if desired).
--
Also, please note that some authorities seem to adress this subject carefully. The French national cybersecurity agency (ANSSI) has for instance published a News bulletin [2] but no "real" Security bulletin of this vulnerability [3].
In its News bulletin, the ANSSI specifies that it also affects Windows Vista RTM :).
However, the ANSSI also says that deleting VSS entries (step 2 of Microsoft recommendations) "must be decided after evaluating the advantages and disadvantages with regard to the risks, in particular because there may be other possibilities for privilege escalation depending on the level of security of your information system."
[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
[2] https://www.cert.ssi.gouv.fr/actualite/CERTFR-2021-ACT-031/
I don't think there are such cases in Linux.
Points 2/3/4 are exactly the same on other OSes, even open sources ones.
Point 1 might be easier to answer by yourself/someone who is not the vendor with open source OSes, while for Windows or OSX you depend on the vendor to tell you with certitude "starting with X" (which they always do). But on the other hand the centralized and streamlined patching model makes it much much easier to identify just which patch caused it, compared to "which level of package mainter or upstream caused it, is it a flaw in SOFT or in debian's SOFT-up3 or what ?"
Point 5 has nothing to do with open source either, on either you can easily test if it's fixed or not. Whether it's considered bug of feature-wont-fix is pretty much always answered so you don't have to actually ask yourself (but if they do consider it normal then you can't fix it yourself on closed source proprietary, though they usually give you a config change to get what you want).
And the same apply to open source software. It's not like all the bugs in open source software was fixed in audits or that you somehow magically know how long time the issue has been attacked by bad actors.
> Through the Shared Source Initiative Microsoft licenses product source code to qualified customers, enterprises, governments, and partners for debugging and reference purposes.
https://www.microsoft.com/en-us/sharedsource/
I say this as someone who doesn’t like Windows and doesn’t run Windows. We still need to admit that Microsoft does indeed let others read the source code, only that they decide who gets to read it and not.
