I would like to know what criteria were considered when ReactOS was designed. As I understand ReactOS is supposed to be compatible with the oldest to the newest versions of Windows eventually. This is very nice and will enable many users to switch from various Windows releases to ReactOS.
Even though I am almost exclusively a Unix/Linux user and developer and that will probably never change I am nonetheless very much interested in ReactOS as a free replacement for Windows. Having tried many WINE releases I have seen it improve tremendously over the years but it will still require a lot of development to enable the majority of Windows applications to run.
Therefore I am confident that ReactOS catches up faster than WINE ever will be able to. It would be very nice if ReactOS could run with 3D acceleration enabled in a virtual machine for applications and games. But since it is developed from the ground up I think its developers shouldn't settle for good enough but rather try to create something better than any version of Windows in terms of stability, reliability and security.
That's why I would like to ask if there is any security built into the operating system or if it suffers from the very same security problems as Windows itself. Something like a noexec flag on file systems, files and folders and a strict separation between superusers and limited users would be very nice.
In this sense I would prefer to see the security features of OpenVMS and Unix and the usability of Windows without ever having to need any anti-software as Windows users are nowadays used to. This is not a critique on the project per se but I wouldn't like this project to repeat the same mistakes Microsoft made when they cut corners creating NT and the Win32 API.
The NT security model is actually an excellent and well designed system when used correctly....
The problem arises when users run as admin by default, which was one of the big mistakes Microsoft made. The same problem would be evident in linux if everyone ran as root.
Due to this 'unrestricted access', software writers became used to having write access to Program Files / system32 and a great deal of 3rd party software was released which did exactly this. To suddenly try and force all users to run in a restricted mode would break many applications, so Microsoft found themselves in a (self made) catch22 situation.
Finally, Vista has addressed this problem by transparantely redirecting applications which write to these folders.
We plan to force all ReactOS default accounts to be restricted and do something similar to vista in redirecting applications to a writable area (e.g. documents and settings).
Thus, although ReactOS will adopt the NT security model, we will be able to enforce the much stricter security policy which Microsoft should have pushed in the first place.
This is just my opinion and people think I'm crazy, but it's old school and old school often works better.
All files belong within its add/driver folder. No exceptions. For example, All files partaining to Eve Online belong the the Eve Folder tree ONLY. There should not be any files for it anywhere else on the drive. And If I want all my games off of \Games insted of program files, then that is where they should go and I shouldn't find ANY files anywhere else. If I want to back up a given app, I should be able to delete that folder and it's gone 100%. That is the problem with that blasted reg.
With the old dos windows 3x etc, they let people dump crap in the system.ini which cause problems and they knew it caused problems. SO how did they fix it? By making a single big system.ini and having everyone dump every bit of crap they could think of in it and then replicate it several times through out. And they called this fix the registry.
The proper way would to have been a install list of sorts. A True registry, When you check into a hotel and are added to the registry, you don't have to give your whole life history, medical records, dna, etc. It gets your name, room number and date. In an os the name would be the name of the program, plus a system generated ID number so you can have more then 1 copy of the same program installed. The room number would be the path to the root folder of the program or drivers tree. For example, I put the game Eve in the games folder. so its room number would be C:\Games\Eve. Add a check box that says it needs to be checked on boot in the case of drivers and such and a disable check box which means basicly skip this entry and you are done. Want to remove the program? delete that tree and that entry and it was never on the system. Neat, clean. In each programs root folder would be a INI which the OS would check for any info needed. No program would be allowed to write in any other programs ini or folder for that matter.
Users would have the option to set some common folders like temp folders, doc folders, etc.
You echo some of my gripes with Windows over the years and I understand what you mean to say here. I don't think there is something wrong with the idea of a registry per se but there is something very wrong when it is contained in a single, easily corrupted file in a central location not normally writable by limited users.
As a Linux user primarily I'm used to a system-wide location (/etc) where default settings are saved and individual settings files in the home directory can override those. KDE and GNOME also have the idea of registries but they have been implemented a lot better since they are collections of folders and individual Text/XML files presented as a single registries and there is no single point of failure. Just delete the faulty settings and move on.
In my opinion the idea of a central location where all programs from all users should be installed does not feel right. Only the superuser should be able to write to the "Program Files" directory. Limited users should have their own "Program Files" directories and their own registries in their home directories.
This is primarily a problem of single-user vs multi-user design that the ReactOS developers should be able to solve. If that isn't done ReactOS will be nothing more than a cheap Windows knock-off replicating the same design mistakes many times made before by Microsoft.
As far as I know Microsoft has something called Installer nowadays that lets you cleanly install/uninstall some software like you do on Linux using RPM/DEB/TGZ packages and that is a good thing. The only thing that I would like to see is that MSI packages can be installed system-wide by the superuser or in the user's home directory when installed by a limited user. And of course the registry settings should be deleted again when the software is uninstalled.
The NT security model is actually an excellent and well designed system when used correctly....
The problem arises when users run as admin by default, which was one of the big mistakes Microsoft made. The same problem would be evident in linux if everyone ran as root.
Due to this 'unrestricted access', software writers became used to having write access to Program Files / system32 and a great deal of 3rd party software was released which did exactly this. To suddenly try and force all users to run in a restricted mode would break many applications, so Microsoft found themselves in a (self made) catch22 situation.
It's good to hear there is a separation between superusers and limited users enforced by the NT kernel system. I've searched around a little on the web but haven't found any in-depth material on the NT security model. But the multi-user design is one of the least of my worries since it should "just work" eventually.
Finally, Vista has addressed this problem by transparantely redirecting applications which write to these folders.
We plan to force all ReactOS default accounts to be restricted and do something similar to vista in redirecting applications to a writable area (e.g. documents and settings).
Thus, although ReactOS will adopt the NT security model, we will be able to enforce the much stricter security policy which Microsoft should have pushed in the first place.
Does that mean that programs that seem to install to "Program Files" are virtually redirected to some other location in the user's home directory and still appear to be installed in the central "Program Files"? This is a laudable move and should be encouraged for all software.
What I am far more worried about is the design flaw in the Win32 subsystem in which any application run by a limited user can send a message to another one run by a super user:
I have a feeling the MAC (dys)functionality in Vista has been primarily enforced because of this irreparable design flaw. I think such functionality shouldn't have been presented to end users by default because of the annoyance it causes. It would have been better to make it an add-on package like Trusted Extensions for Solaris 10 or Red Hat's SELinux. But because of the Win32 design flaw it has become necessary to prevent even limited users from wrecking the system.
Have the ReactOS and WINE teams implemented the Win32 API in a safer way that doesn't suffer from the same security problem? I understand ReactOS aims to be compatible but this is a very serious design flaw that shouldn't be simply replicated without taking precautionary measures.
The only operating system I know of which actually sticks all files that are installed with a program into the same directory as the program is GoboLinux. No one else does it that way, and even they don't exactly permit you to just delete a folder and remove the program that way, since that could play hell with the symbolic links they use to maintain consistency.
No, we are not going to forcefully redirect writing from program files to some local user directory. Not sure why that's even being brought up. Ged stated that we'll redirect attempts by programs to write into the System folders back to their own local folder, which is likely to be in Program Files anyways. We are not trying to redefine the directory hierarchy here.
SeLinux is NSA. Debian produces large amount of the Selinux profiles for applications. Redhat is only one of the teams working on Selinux.
The design flaws in Windows NT are repairable.
Being open source there is nothing stopping people adding stuff like Selinux to Reactos. Big problem is lack of application profiles describing what the application is permitted to do..
i beleive that the next version of windows - currently codenamed vienna, is taking drastic action in order to protect the system from the vagarities of win32
everything is sandboxed and all access to the system is regulated.
So in vienna, the OS will try to spot when someone is trying to pull of that WM_TIMER attack that was mentioned in the earlier link, and will silently refuse it access to the LocalSystem process, or something like that.
They are also dropping a lot off legacy stuff in order to keep the potential number of things that can go wrong (attack 'surface area' is the buzzword) down.
{little off topic}
The problem with Windows registry is not only with its central location.
Whenever an installer installs a program it creates/modifies a lot of entries (may not be for a simple program but more so for most of the commercial programs) in many places in the registry. Even a clean uninstall using the uninstall program that comes with it does not successfully remove all those entries.
For a normal user it is very difficult to locate and isolate such entries. This is made use of by many unethical programmers to create malware.
Further even in case of good programs whether due to corruption of entries or intentional, things go wrong. This leads to such a state that a complete reinstall of Windows is the only option for a simple problem. Some need a third party program to remove all of the entries created by them.
(Just as an example I would like to give my problem with Nokia PC Suite right now. I had installed and used it earlier. Due to some reason I had to uninstall the PC Suite. Thought I will reinstall it anyway. Later reinstall has not given me my connectivity back. This is because the connection manager refuses to recognize my phone. Another instance was the dialer provided by my ISP. Due to a scratched CD it only installed a part of it. Further attempts to install using a good CD resulted in a 'Program already installed' error. Uninstall could not be done cause there was no uninstaller installed!)
This could be corrected if the settings were all contained in a single directory or a separate/clearly named file which can just be deleted.
Just my frustrated thoughts
-SS.
I am a nobody. Nobody is perfect. So I am perfect.
psychicist wrote:
Does that mean that programs that seem to install to "Program Files" are virtually redirected to some other location in the user's home directory and still appear to be installed in the central "Program Files"?
yes
What I am far more worried about is the design flaw in the Win32 subsystem in which any application run by a limited user can send a message to another one run by a super user:
Z98 wrote: Ged stated that we'll redirect attempts by programs to write into the System folders back to their own local folder, which is likely to be in Program Files anyways. We are not trying to redefine the directory hierarchy here.
The way I install and expect to find files on my system, is, game files go in the respected games folder in "c:\games", Cad and paint programs go in "c:\Art", network software goes in "c:\Online", music and sound files go in "c:\music", general utilities go in "c:\utils". And next setup I do, all that will be on another drive. Only the OS and drivers will be on c:. And yes I do have a "c:\misc" folder for stuff that dosn't really belong anywhere else.
The problem with crap code by lazy programmers was address by a version of wine/dx9 linux that was out some time back. Not sure if it still is. Windows programs were each given their own registry and tree on install. They tried to dump somthing in \windows, the program thought it got away with it, but the windows folder it dumped in was in the apps own tree. So it was not scattered all over. And if a program screwed up the reg on install, it only messed itself up. And when it came time to undelete, clean up was 100% because you just deleted that tree and any reg crap it created was also gone without effecting any other programs. They where in a sence forced to use their own ini.
If all programs did that, no program could interact with another one besides using a network. I could take that for stability, though. Some people couldn't.
It is still really annoying. I don't see that as a solution.
Under wine each user has there own copies of applications.
Particular applications need to interact with each other like Qucktime and some games.
Lack of profiles on what applications should be doing makes making a secuirty setup hard. The registry in windows is a lot hardder to handle than application config files on working out what needs to be shared between apps.
Some one might have a really good solution somewhere. There has to one. Windows is where Linux was pre 2000. We were all pulling our hair about it up until NSA took the lead and said this way works lets go with it.
Programs can interact where needed without dumping crap all over the drive or in other apps folders. A lot of so called interaction is crap pushed out by MS that is not only not needed but is a bad thing being the source of many infections. For example there is no reason to ever have any kind of file managing commands imbeded in a image or doc file. Yet someone got the brain dead idea to put them in and now we have both doc files and jpgs that can carry viruses. This goes all the way back to ANSI, doing stupid things like including ways to run the format command. So you couldn't have ansi graphics with out worrying that someone would include format c: in the code.
!