[Apologies for the length of the reply; it is a longish one. -Mike]
Sarocet wrote:
I had an idea about virus propagation. As we'll have added attribs on FS, i'd implement the eXecution flag. No program could be run without it. If a DLL were loaded it'd have that flag would automatically set (if allowed). If you try to run a program, the explorer.exe or whatever else program tha tried to call it must ask the user for permission or handle the adding in an efficient way. If you modify, append, or in whatever method change a file, the +x would be reseted. Any program can set that flag on, BUT if before it gets set, the system calls a DLL (could be an exe, but it should stay in memory as it can be very frequently called...) that checks it for virus. If it's ok, it allows the flag. If not, the flag is not set (it doesn't remove it, as it have never been set). Then the DLLs can be very different, they can check it into an internal virus database, ask about it at the ROS website (the problem'd be to determine what it can give apart of a hash, that not reveals personal informetion, a filename or path can reveal too much), give it happily (first implementation), ask the user if (s)he's experienced (if not, the dll loads can be very annoying :D)...
For one thing, Win32 (the NTFS filesystem) already provides for this. All files are created with the "Read & Execute" permission set on by default. This is why there can be problems when exchanging files from a Windows box and an improperly configured Samba box if you are trying to retain security on it by disallowing execution.
However, the whole idea is sort of like the (rather broken) general permissions system of Windows. It's hard to fix it without breaking a lot of programs and making things difficult for the end-user; in order to do nearly anything, you need Admin privileges. If you start restricting everything by default and expecting the user to actually administer their box, you're introducing confusion and likely driving people away from using what is (read: will be) a very high-quality system.
Microsoft has claimed to have started to make a transition to a more UNIX-like way of handling permissions, which would be safer and more secure, where Admin rights aren't needed everywhere you go. Part of it is that Windows will prompt you to run files and let you know if they're "signed" or not. That's a worthy system to support. It doesn't get terribly much in the way of the end-users, and it helps to boost what the end-user can do to create a more secure environment both standalone and networked.
The permissions thing is already in the system layout, it would just need to be *used.* In fact, Windows, and the Win32 way of working with the filesystem, provides for total ACLs and such that Linux/UNIX filesystems, AFAIK, are pretty new to. You can have ACLs with ext2fs/ext3fs, IIRC, and if those systems are used with ReactOS, it'd make a great pairing. Probably so with ReiserFS, too. It'll be a long time before NTFS is supported natively, I think, but the permissions system is something that can be used on other filesystems that support it.
As that flag can be set to any file, programs that use macros, must then -to be compliant- confirm before that the file has +x. If not, load without macros, ask the user, not load... That aplies to WSH, Java, Flash, Php, shell scripts...
That would be extremely difficult to do. You're then expecting the filesystem to know everything about every single file that is on the system. Rather, it'd make more sense to try to get things so that they don't run with privileges that are able to really do any damage; that's how control is given on UNIX systems. I don't +x my PHP scripts on the web server; I do, however, have the Web Server set up to run as a user without permissions to write anywhere except for its own log directory. That helps to keep the environment safe.
Perhaps a better idea here would be to create some mechanisms in the system that can retain compatibility with the Win32 way of doing things (run as a privileged user all the time) and the best practice way of doing things (run as a regular user for anything that doesn't explicitly need administrative rights) and educate the users on that. This relives some of the burden on the operating system and puts it back into the hands of the network administrator/system administrator. Development workstations, such as what you find in someone's home, are traditionally behind a NAT, and if a dev is silly enough to run scripts that they haven't at the very least reviewed... Well. *shrugs* There's something to be said for "due diligence" to system security, and if you're a developer, even just for something like small PHP or ASP Web projects (under 5 files), you should be able to know to look before leaping.
FS like FAT would have then an index file with the programs with +x, some kind of system to emulate it. Removable devices (USB sticks, CD-ROMs, floppy-disk...) must not have +x flags. A remote computer can think it's secure but our computer (note that we can't be sure we're the same, everything can be faked) must not trust on it. +x should only stay per session, not allowing the user to set it. If a +x flag is found set, the system must ignore it.
You may recall; that's how Windows implements VFAT; they added hacks into their FAT filesystem drivers to support the features that Windows 95 attempted to make so popular, with long filenames and the like. This was done similar to the volume label hack way back in the days of MS-DOS when they added the Volume Label as a special portion in the BPB, as well as a hidden file that had an impossible attribute set attached to it. The FAT system isn't really reliable and I don't think that it's really safe to add new "features" to it - it's one filesystem that was so poorly designed that it's seriously only good for short-term use on removable media.
The system'd be more secure and only executable files get scanned, and only once so it's fast (by the way, i have to disable my antivirus before updating svn, as it tries to scan them all, so it slows a lot). If you think you've a virus, or simply monthly, for example, you can ask a program to reset all +x flags (no check is done to remove it), so your programs will be scanned next time :-)
It sounds like what you're suggesting is that the system should assume that each file gets to "earn" the executable attribute, and then you can assume that unless the user pulls the attribute, the file is safe. That's not really a good idea; users tend to be pretty bad housekeepers when it comes to computing. It's best to leave the system work without trying to introduce new points of failure, regardless if said new points of failure are in the technical aspect of the system, or in the user aspect of the system. Virus scanners do their jobs pretty well by default, and you can configure them to streamline their performance so that on-access scanning requests can be queued and what-not, helping to streamline SVN/CVS updates, archive extraction, and so forth.
I know that my scanner keeps an internal database of when it does sweeps, does on-access scanning, and I have it configured to perform one full system sweep once per week, when the computer is known to be idle, without impacting any performance on what I do or when I work on the system. I don't notice *any* performance hit on the on-access scanning, either, even when using the web (I have a very large cache size for images and the like, and that is constantly being hit by the OAS part of my AV system, without a hit).
The benefit of this is that as it'd be implemented at low level (driver, or between driver and system), it can be more secure, with less work.
It actually sounds like it'd create a veritable load of problems; essentially, breaking compatibility with Win32 and how Windows does things. Remember, the system needs to come out being compatible, that's one of the design goals.
It sounds like one of the better ways to go about handling this would be to use the process management aspects of the system to reduce the execution priority of the virus scanner toolset; this would enable the system to not lose any performance to a virus-scanner, while keeping the system running at a proper speed. I don't think changing the system's interfaces is the answer to this, in any case.
Regards, Mike