Page 2 of 4
Posted: Wed Jul 11, 2007 11:21 pm
As a general rule, the user should have some way of defining behaviour.
For example being able to isolate a particular application in it's own 'glass box' where everything is stored in a single directory, should be possible, but not enforced.
This can be system wide, or application specific.
In order for this to work though the system needs some mechanism for tracking what applications are installed and where.
Obviously defining an API won't work, since you can't rely upon ISV's to follow Reactos.
And obviously the current uninstall registry key system is not adequate since that doesn't neccesarily have all the information required, and not everyone uses it.
instead a independent register of applications that cannot be arbitrarily modified by applications without admin priviledges (and seperate from any other legacy win32 system to avoid that gotcha) should be set up.
This containing the results of a sort of 'analysis' of applications based upon the entries under %programfiles% (or any other location the user designates as a install location perhaps maybe %programfiles% could become a comma seperated list like %path%...), records of access to the registry and other system locations/files, and what .exe's and other executables have loaded and where, and what they do. It can then keep track of what registry entries and system files are 'owned' by what application, as well as monitoring for any unexpected changes.
Profiles could be supplied with programs to circumnavigate the need to 'analyse' the program file entry (ie. you can either submit the information to the system, or the system will watch you, all programs written with windows in mind will have to have to be watched)
With this system you can have several cool things, 1stly you can have an 'interaction status' for a program, specifying whether it's registry entries and it's system files can be seen by other programs. and whether it can see others. (I can imagine that this might create clashes, but again the users discretion is paramount) On top of this there is the possibility of having a 'force clean uninstall' option, which removes all trace of the program, or even a 'roll back' option which puts everything back the way it was when it was first installed.
There are also good security implications for this. If we can assign a trust system to programs, then programs that are 'untrusted' can have restricted access and a very conservative interaction status unless manually overwritten by an Admin. A program that hasn't provided a profile that shows safe behavior, can cause the user to be prompted as to whether the program should be trusted or not(might be annoying, will include every classic win32 app under the sun). Likewise if a program starts exhibiting behaviour outside of it's profile, it can be shunted down to a much lower trust level.
I beleive that SElinux is something similar in terms of security, the main thing is the system of tracking what is installed. This needs to be done in terms of .exe's loaded and in terms of entries in installation folders ie. %programfiles%
PS: naturally this framework might not fit the bill of a 'lightweight' win32 system. Perhaps make this optional...
Posted: Thu Jul 12, 2007 7:39 am
Vorg jpegs should not harm any upto date system. There problem was caused by a buffer overflow bug.
SELinux is different because makers following can be enforced. Nice ideas cppm getting SELinux style protections without the support of application makers is going to be fun to say the least.
Posted: Fri Jul 13, 2007 9:01 am
oiaohm wrote:I hate when people get things wrong.
SeLinux is NSA. Debian produces large amount of the Selinux profiles for applications. Redhat is only one of the teams working on Selinux.
I'm perfectly well aware that SELinux is an NSA technology but Red Hat was the first to integrate it into a general purpose Linux distribution.
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..
Could you tell me what the plans to do so are? I haven't seen or read anything about that at all. All I've seen is "we want to be compatible with Windows up to the point that we clone all behaviour including design flaws".
Posted: Fri Jul 13, 2007 9:12 am
Vorg wrote: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.
That's exactly how I tend to install programs in WINE. Each major application has its own WINEPREFIX so there is no interference between different programs. They get a pristine Windows environment. Codeweavers calls them bottles and has a GUI for creating them.
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.
This is exactly the kind of clean behaviour I would like ReactOS to support because I have given up on Windows long ago but I remain positive of ReactOS.
Posted: Fri Jul 13, 2007 9:27 am
Vorg wrote: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.
If you really need that interaction isn't it possible to install that software to the same wineprefix? That would look like a sane approach to me at the expense of disk space. Hard drives are huge nowadays so that shouldn't present insurmountable problems.
All too often I've seen applications conflicting with each other when installing a huge number of them. This approach would make it a lot easier to manage. KISS is an admirable principle to adhere to, even on Windows-like operating systems.
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.
That's why I never ever embed macros into documents. The way it's done nowadays is just a matter of convenience trumping security. It's way better to send the document and the code in separate documents, ideally an ODF and a Basic/Java/C++/Python file that has to be installed locally.
This and setting local macro security to the highest level or disabling them altogether prevents many attacks that are common nowadays.
Posted: Fri Jul 13, 2007 4:47 pm
STOP double/triple posting. I am not going to go to the effort of merging your posts. Next time I'll just start deleting them.
Posted: Fri Jul 13, 2007 5:10 pm
Z98 wrote:STOP double/triple posting. I am not going to go to the effort of merging your posts. Next time I'll just start deleting them.
You could have just asked instead of treating me as a hostile person. Next time I'll start combining my posts. The forum software gives me no way to do that with my previous posts otherwise I would already have done so.
That aside I am not just a user. I was looking forward to contributing to ReactOS development if it lived up to my expectations and possibly even port it to MIPS (I have just ported Slackware to MIPS). Ged seems to be pretty positive of my questions but I'll have to think it over with people like you around.
Posted: Fri Jul 13, 2007 9:27 pm
No offense, but he does have a point. Please, just edit an old post.
Posted: Sat Jul 14, 2007 4:16 am
psychicist Redhat was not first to integrate selinux. There were many before them. Most of them were hardened forms of linux's that could be used for any task. It still does not make calling it Redhat Selinux right. Thinking that 70 percent of the Selinux profiles in Redhat started in Debian. I expect people to respect the inventors. Selinux is NSA Selinux or the group project of different Distrobutions. Redhat, Debian and a few others share there profiles between each other.
Vista provides injection control limited to DRM apps. This kind of protection could be put across all applications as a administrator tool. Really reverse it only permitted applications can inject into other applications. Thinking that most applications don't inject into other applications its effects should be completely minor. This is a instant kill of about 50000 viruses for windows since the inject them self into another process to hide them selfs before replicating. A virus that cannot replicate is a dead virus.
Its also like Reactos React X still be designed around the Windows 2000 Direct X model not XP's due to the Windows 2000 one being more security sound.
In Vista users don't run with full system power all the time. It was a really foolish thing to be doing.
Windows NT design has good secuirty controls in a lot of ways in the same classes as selinux. Just needs to be expanded to cover as much as selinux. Windows XP is very much the same as running a distro with selinux with selinux disabled completely since most of the secuirty policies don't apply to the administrator user.
It is really bad that X version of windows dos not have X problem but has Y defect. Y version of Windows has Y fixed but has X as a problem. Part of fixing the design flaws is not coping the flawed sections. Some are expanding what Microsoft has done. Others are truly enabling what is there.
Windows NT Security is able to allow cd burning and other device access as a limited user without risking the complete system.
Biggest problem to take on is the idea of registry. Single store of configurations Secuirty of Windows NT was not really build or expanded to handle this completely. Added the means to store security permissions inside the registry would fix a lot of problems allowing key by key permissions. Now is this a problem that cannot be over come no it can be. One of the big things is under X key place in user own registry even if it should have went into the system hive. Ie kicking bad applications out of placing there user keys in the system hive.
More support for using winsxs can sort out dll hell. Use of different prefexs would be a complete last option.
As you can see Reactos can be is own beast. With its own advantages. Lot of the tech to make a great version of Windows Microsoft has released. Problem they just never manage to release it in one version.
Posted: Sun Jul 15, 2007 9:31 am
psychicist wrote: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.
eventually the registry just grows like an amorphous blob and can eventually slow the system just due to its size and the constant queries, adds and deletes to it. it seems like whenever an app is installed it adds keys and whenever it's uninstalled they never quite get them all (and i'm not talking about the "recent" type menus).
Posted: Sun Jul 15, 2007 10:54 pm
If programs where forced to write their entries in their own ini, cfg, reg, whatever, you wouldn't have that problem. Removing 100% is as simple as removing that programs tree which would take with it it's part of the "registry". Then just remove the pointer from the real registry.
Even if you have to assemble at boot each programs file into one ram based registry for compatibilty, The working registry would be clean because there would never be any left over crap, no blank spaces from removed entries, etc. And gathering data from each programs reg file that needs to be loaded at boot should still be faster then going around the harddrive gathering a fragmented and bloated registry full of leftover junk and entries for programs that are only needed when that program is run.
Posted: Sun Jul 15, 2007 11:00 pm
I can't remember what GUI or OS does this, I think it is a DOS GUI, but, all programs put their config files in one folder. The registry is created from all of those files. Program uninstaller deletes these files. Every write to the registry updates the files. Any blank configuration lines do not get loaded.
Posted: Mon Jul 16, 2007 2:07 am
Early Windows Reactor. I cannot remember what one it was either 3.11 or before. Microsoft changed to a binary format we have now because of the idea it would be faster.
KDE and Gnome do a similar thing for there equal to a registry as well many single files binding into a single accessible list.
And the stupid part is the lack of registry in linux is a common thing MS trained people complain about in linux.
Registry defraging is important. Windows was bad because it never shiped with a tool to do that and still does not.
Other problem with Registry design it does not have security options on a per key or key set or what application created the key and what application last altered it. This is the major advantage of the individual files method. This is not imposable to do in a binary format like a registry.
Linux uses a package manager for removal for very important reasons. Just deleting a program another program depends on its not a good thing.
Even Linux package manager leaves behind minor trash of config files. Not hard to clean up because you know what they owned to.
The error here does not change the question is the right way to fix it.
Posted: Tue Jul 17, 2007 3:28 am
psychicist wrote: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.
Sorry to slam your bubble with a sledgehammer, but ROS ain't Linux. You want that design idea? Stick with Linux, or code it in to a custom ROS build yourself.
Posted: Tue Jul 17, 2007 4:31 am
oiaohm wrote:Early Windows Reactor. I cannot remember what one it was either 3.11 or before. Microsoft changed to a binary format we have now because of the idea it would be faster.
faster and fatter