It's one thing to make device drivers work that's a critical goal of this project. ReactOS is in a state where its developers can demand better design from application vendors. Yes, it meant a lot of security hacking to make broken apps work, but if I had a choice of better designed apps to do the same job, I would pick those and hack less. I can boast a 100% malware-free record for clients I consulted for, without using anti-virus software. I've used this approach in Windows 2000 before with great success. Yes, hackers could come up with ways to work around that, but at that point it's plausable to blame the user for running those things. Instead, I'd put admin password prompts on only a few specific things that change the computer, such as adding or removing apps, manipulating devices or user accounts, or editing the system-wide portions of the Registry. Any attempt to do so should auto-logoff if possible. If I were developing a security model for ReactOS, I wouldn't even permit logging on to a shell with an admin account whatsoever. Mozilla already develops such things with Firefox, for instance, which runs under a limited account on Windows XP without hacking. If ReactOS is to differentiate itself from Windows in security, it should do so by requiring security-aware applications. That job falls in the laps of the application developers. Making security-ignorant applications work is not ReactOS' job. And it all reads like it's in the name of making broken applications work. It seems to tell a story about differentiating ReactOS security from Windows security, yet this article looks just like the original Microsoft solution to the security problem: Making it as easy as possible to get to Admin. I read the UserSecurity article in the Wiki.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |