As recently the discussion about a firewall and a virus-scanner came up again, I thought of a new thing, that is a bit different than the already known things.
My idea is not to use a firewall and a virus-scanner, I want to create a new service, that may be configured by a gui, a console app or by other apps, that might use some of its features. This service should do the following things:
- Having a look at the network traffic, which includes the following: - Controlling, which application may use the network connections - Controlling, how many traffic they cause, which could warn the user about suspicious actions - Watching the running processes for unusual events - Checking every file that is read or written for viruses - Scanning the http-traffic for ads and viruses
But the most important thing for me is that if this service is shutdown without the user agreeing to that, which may be checked by ntoskrnl, the user should be informed about it and nearly all network traffic should be blocked. Then the network-card should be deactivated, all userprocesses should be paused and all drives should be checked for viruses.
I think this is hard, but it will make it much harder for worms to spread, as they don't have the chance to deactivate our securitysuite and so they will be detected within two days and if they try to shutdown the securitysuite they have no chance to spread. That would be more secure than any other existing OS.
This are just a few thoughts, feel free to change it the way you like it.
Greets,
David Hinz
I think that is great.
I too have an idea.
How about a spell checker that intagrates into all running apps. i.e. If I install a database I would like to spell check the data even if the app does not have this feiture. The OS should have it. SkyOS has this feiture.
On 11/15/05, David Hinz post.center@gmail.com wrote:
As recently the discussion about a firewall and a virus-scanner came up again, I thought of a new thing, that is a bit different than the already known things.
My idea is not to use a firewall and a virus-scanner, I want to create a new service, that may be configured by a gui, a console app or by other apps, that might use some of its features. This service should do the following things:
- Having a look at the network traffic, which includes the following:
- Controlling, which application may use the network connections
- Controlling, how many traffic they cause, which could warn the
user about suspicious actions
- Watching the running processes for unusual events
- Checking every file that is read or written for viruses
- Scanning the http-traffic for ads and viruses
But the most important thing for me is that if this service is shutdown without the user agreeing to that, which may be checked by ntoskrnl, the user should be informed about it and nearly all network traffic should be blocked. Then the network-card should be deactivated, all userprocesses should be paused and all drives should be checked for viruses.
I think this is hard, but it will make it much harder for worms to spread, as they don't have the chance to deactivate our securitysuite and so they will be detected within two days and if they try to shutdown the securitysuite they have no chance to spread. That would be more secure than any other existing OS.
This are just a few thoughts, feel free to change it the way you like it.
Greets,
David Hinz
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- David Johnson http://www.davefilms.us
It'd be an added feature for the Edit control. If you right-click a select text it offers you a new menu with the ability to spell-check it. I don't think it difficult to implement (i have no idea where is the edit control defined). However, i'd be better if it were not static. So it loaded cut, copy, paste, select all, menus and then check in the registry for more menus. If they're it adds it, and when you press the button, the DLL associated to that menu gets the control handle and do whatever it wants: modify the text, show a spell-checking window, open a web page about that word.... It'd give you more flexibility. Why only a spell-checker and not a translator? or whatever you want. Apps could install it.
Possible problems/Notes: -Menus available only if writing-acces to the textbox. That may be annoying for read-only menus but it should stay for the program stability, unless we stablished two menu-types. Read-only and read-write. (If they say they are read only, write access force to denied). Of course if they are for passwords, not special menus. Not matter how they introduce themselves. -The DLL should only be loaded when the menu is pressed. If called when loading the Edit, it wastes memory you may not want and makes the system slower, AND if the DLL is badly made, it can crash the system, as edit controls are used everywhere. -The user must be able to add/del entrys easily. I don't want to have when i right-click on a word, options to look it up on google, google news, yahoo, wikipedia, translate with babelfish... I'll add what i want, and delete everything else. Spyware, toolbars, etc. will wish to add themselves. A control panel menu recommended.
----- Original Message ----- From: David Johnson To: ReactOS Development List Sent: Tuesday, November 15, 2005 10:02 PM Subject: Re: [ros-dev] Security Suite
I think that is great.
I too have an idea.
How about a spell checker that intagrates into all running apps. i.e. If I install a database I would like to spell check the data even if the app does not have this feiture. The OS should have it. SkyOS has this feiture.
I would say that that is a good idea.
On 11/16/05, Sarocet Sarocet@spymac.com wrote:
It'd be an added feature for the Edit control. If you right-click a select text it offers you a new menu with the ability to spell-check it. I don't think it difficult to implement (i have no idea where is the edit control defined). However, i'd be better if it were not static. So it loaded cut, copy, paste, select all, menus and then check in the registry for more menus. If they're it adds it, and when you press the button, the DLL associated to that menu gets the control handle and do whatever it wants: modify the text, show a spell-checking window, open a web page about that word.... It'd give you more flexibility. Why only a spell-checker and not a translator? or whatever you want. Apps could install it. Possible problems/Notes: -Menus available only if writing-acces to the textbox. That may be annoying for read-only menus but it should stay for the program stability, unless we stablished two menu-types. Read-only and read-write. (If they say they are read only, write access force to denied). Of course if they are for passwords, not special menus. Not matter how they introduce themselves. -The DLL should only be loaded when the menu is pressed. If called when loading the Edit, it wastes memory you may not want and makes the system slower, AND if the DLL is badly made, it can crash the system, as edit controls are used everywhere. -The user must be able to add/del entrys easily. I don't want to have when i right-click on a word, options to look it up on google, google news, yahoo, wikipedia, translate with babelfish... I'll add what i want, and delete everything else. Spyware, toolbars, etc. will wish to add themselves. A control panel menu recommended.
----- Original Message ----- *From:* David Johnson davidjohnson.johnson@gmail.com *To:* ReactOS Development List ros-dev@reactos.org *Sent:* Tuesday, November 15, 2005 10:02 PM *Subject:* Re: [ros-dev] Security Suite
I think that is great.
I too have an idea.
How about a spell checker that intagrates into all running apps. i.e. If I install a database I would like to spell check the data even if the app does not have this feiture. The OS should have it. SkyOS has this feiture.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- My DeviantArt.com page: http://crashfourit.deviantart.com/ My FanFiction.net bio page: http://www.fanfiction.net/u/726606/ My Blog: http://crashfourit.blogspot.com/ America's Debate: http://www.americasdebate.com/
Sarocet wrote:
It'd be an added feature for the Edit control. If you right-click a select text it offers you a new menu with the ability to spell-check it. I don't think it difficult to implement (i have no idea where is the edit control defined). However, i'd be better if it were not static. So it loaded cut, copy, paste, select all, menus and then check in the registry for more menus. If they're it adds it, and when you press the button, the DLL associated to that menu gets the control handle and do whatever it wants: modify the text, show a spell-checking window, open a web page about that word.... It'd give you more flexibility. Why only a spell-checker and not a translator? or whatever you want. Apps could install it.
they're called text services, Windows supports them since Windows XP and the framework to run them is available for Windows 2000 too
David Hinz wrote: [snip]
I think this is hard, but it will make it much harder for worms to spread, as they don't have the chance to deactivate our securitysuite and so they will be detected within two days and if they try to shutdown the securitysuite they have no chance to spread. That would be more secure than any other existing OS.
I think that this may be a little bit beyond hard. I'm not a developer, per se, but I can understand a great deal of what would go into things. Creating a firewall "service" isn't a bad idea at all -- this allows the user to enable/disable it and choose something else, if they want. But I fail to see how you expect the OS kernel to work to verify that the end user is what created the action to disable the service, since the kernel is pretty far away, relatively speaking, from the GUI and additional software that's used to interface with the system software. It could be done a la WinXP SP2 where a popup window comes up when ReactOS detects that there isn't something running to protect the user, which could be disabled by the user at will. I think that's good, because it gives the user even more choices, and ReactOS would be able to watch more then just its own modules/services that way.
I'd hate to think what would happen if the user had some different means of controlling the running services on the workstation or server, and ReactOS interpreted its shutdown of the "Security Suite" as a malicious act and then blocked the user from the entire machine, especially if they're remotely working on it.
In a nutshell, it would be more secure then any existing OS, sort of. But I don't count any potential for a DoS to be a security plus.
- Mike
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)...
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...
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.
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 :-)
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.
----- Original Message ----- From: "David Hinz" post.center@gmail.com Sent: Tuesday, November 15, 2005 9:25 PM Subject: [ros-dev] Security Suite
As recently the discussion about a firewall and a virus-scanner came up again, I thought of a new thing, that is a bit different than the already known things.
My idea is not to use a firewall and a virus-scanner, I want to create a new service, that may be configured by a gui, a console app or by other apps, that might use some of its features. This service should do the following things:
- Having a look at the network traffic, which includes the following:
- Controlling, which application may use the network connections
- Controlling, how many traffic they cause, which could warn the user
about suspicious actions
- Watching the running processes for unusual events
- Checking every file that is read or written for viruses
- Scanning the http-traffic for ads and viruses
But the most important thing for me is that if this service is shutdown without the user agreeing to that, which may be checked by ntoskrnl, the user should be informed about it and nearly all network traffic should be blocked. Then the network-card should be deactivated, all userprocesses should be paused and all drives should be checked for viruses.
I think this is hard, but it will make it much harder for worms to spread, as they don't have the chance to deactivate our securitysuite and so they will be detected within two days and if they try to shutdown the securitysuite they have no chance to spread. That would be more secure than any other existing OS.
This are just a few thoughts, feel free to change it the way you like it.
Greets,
David Hinz
So it's a performance optimization? Once an executable image is first cleared by the virus scanner, it doesn't have to check the file for viruses again until the file is written to. I would imagine that any mature virus scanner would keep track of files that were recently scanned so it doesn't have to scan them again.
Casper
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Sarocet Sent: 16. november 2005 17:26 To: ReactOS Development List Subject: Re: [ros-dev] Security Suite
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)...
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...
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.
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 :-)
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.
----- Original Message ----- From: "David Hinz" post.center@gmail.com Sent: Tuesday, November 15, 2005 9:25 PM Subject: [ros-dev] Security Suite
As recently the discussion about a firewall and a virus-scanner came up again, I thought of a new thing, that is a bit different than the already known things.
My idea is not to use a firewall and a virus-scanner, I want to create a new service, that may be configured by a gui, a console app or by other apps, that might use some of its features. This service should do the following things:
- Having a look at the network traffic, which includes the following:
- Controlling, which application may use the network connections
- Controlling, how many traffic they cause, which could warn the user
about suspicious actions
- Watching the running processes for unusual events
- Checking every file that is read or written for viruses
- Scanning the http-traffic for ads and viruses
But the most important thing for me is that if this service is shutdown without the user agreeing to that, which may be checked by ntoskrnl, the user should be informed about it and nearly all network traffic should be blocked. Then the network-card should be deactivated, all userprocesses should be paused and all drives should be checked for viruses.
I think this is hard, but it will make it much harder for worms to spread, as they don't have the chance to deactivate our securitysuite and so they will be detected within two days and if they try to shutdown the securitysuite they have no chance to spread. That would be more secure than any other existing OS.
This are just a few thoughts, feel free to change it the way you like it.
Greets,
David Hinz
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
----- Original Message ----- From: "Casper Hornstrup" ch@csh-consult.dk Sent: Wednesday, November 16, 2005 6:18 PM Subject: RE: [ros-dev] Security Suite
So it's a performance optimization? Once an executable image is first cleared by the virus scanner, it doesn't have to check the file for viruses again until the file is written to. I would imagine that any mature virus scanner would keep track of files that were recently scanned so it doesn't have to scan them again.
Casper
Virus scanners can do whatever they want. Of course, they should keeping track of files, but it's an internal implementation. I'm not wanting users to avoid virus scanners. I'm talking about a way to ensure security on ROS, not to discard virus scanners.
Mike: "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." I'm not expecting the FS to know everything. Only to know when files change, and i think it's pretty easy as programs must use system calls to change files.
"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" If the programs doesn't have +x, they are not expected to be run, so they should run with any privilege. If the program can be run, then we should determine what is privileged to do, they don't exclude (but programs will usually be run under the privileges of user's account).
"I don't +x my PHP scripts ..." - I don't talk about making php files executables (they are not .exe, are they?), i'm talking of a way to control that files are not modified, and then programs should use it, to control what are files expecting it to do.
About the FAT. I agree that FAT has not chance of improve, i was talking that if i has a FAT partition, the system should have some 'hack' to remember the attrib.
"...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..." Well, if it's not implemented, there's not such limitation so it's not a new point of failure. It's a new control method. However, it could be ok to have it pre-configured to reset +x autamatically each week, for example.
"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 doesn't need to break compatibility. Programs should know that LoadLibrary can fail, and if they want to run a program, that program can even not exist.
"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." what are you talking about?? :S
Summing up, this would only be a new layer to check files. I can be so soft as a "accept to all", search for virus, ask the user for permission (as firewalls do), or determine in function of the folder, filename and date if the program can run or send a copy to an online virus scanning while shutdowning the computer and calling the police. ReactOS is an open OS, so many implementations would be available, and everyone could make its favourite without problems. That's the way i'd like it to work, a way i think better than microsoft's of giving execute permission to everyfile. Specially if it's considered that windows antivirus will not work in a long time. But if ROS community determine that it's not a good idea, i have no problem.
[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
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).
execution already has to be granted by the file's ACL. It just happens to be enabled by default (try disabling it to see by yourself why it cannot be disabled without trouble)
That aplies to WSH, Java, Flash, Php, shell scripts...
no, it doesn't. You cannot tell between opening and executing a script
Make it happen.
On 11/19/05, KJKHyperion hackbunny@reactos.com wrote:
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).
execution already has to be granted by the file's ACL. It just happens to be enabled by default (try disabling it to see by yourself why it cannot be disabled without trouble)
That aplies to WSH, Java, Flash, Php, shell scripts...
no, it doesn't. You cannot tell between opening and executing a script _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- David Johnson http://www.davefilms.us
And while you're at it, please solve the world's hunger problem and find a cure for cancer too.
_____
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of David Johnson Sent: Saturday, November 19, 2005 19:14 To: ReactOS Development List Subject: Re: [ros-dev] Security Suite
Make it happen.
On 11/19/05, KJKHyperion hackbunny@reactos.com wrote:
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).
execution already has to be granted by the file's ACL. It just happens to be enabled by default (try disabling it to see by yourself why it cannot be disabled without trouble)
That aplies to WSH, Java, Flash, Php, shell scripts...
no, it doesn't. You cannot tell between opening and executing a script _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I'll get on it right away. I think Dialysis can cure cancer. Genitic enhanced crops will do the trick. Soilent Green is good too.
On 11/19/05, Alex Ionescu ionucu@videotron.ca wrote:
Ge van Geldorp wrote:
And while you're at it, please solve the world's hunger problem and find a cure for cancer too.
Yay for blue color-coded 6KB HTML replies!
Best regards, Alex Ionescu _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- David Johnson http://www.davefilms.us
KJKHyperion wrote:
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).
execution already has to be granted by the file's ACL. It just happens to be enabled by default (try disabling it to see by yourself why it cannot be disabled without trouble)
That aplies to WSH, Java, Flash, Php, shell scripts...
no, it doesn't. You cannot tell between opening and executing a script
The programs should check it for executing a script too (or give the user the chance to check it or not. I quote form my email "-to be compliant-" ), as it verifies we're not doing malicious actions.
My idea was to set a file flag that stated that its file was 'clean' (whatever clean could mean). This was restricted by the system/river resetting it when the file changes and only allowing to set it through an special tool that would be responsible to see if it's clean or not (could simply say everything is clean or study them more carefully, it's up to the implementation).
Of course something like this could be implemented without so restrictive checking. Maybe using the +m flag. Let's suppose files without it are clean. What then? If i tryed to make such a program using the modified flag it'd be a mess. Some programs set it when editing. However, others not. I could get a new (infected) file, and it could show as not dirty... That's why i thought it interesting, as a way to have everithing controlled, without having to virus-check always everything. Of course regularly or when definitions update it'd expire, but i think is easy and powerful enough to provide a not-so-insecure os.
By the way i tried to change the execution flag on windows but i couldn't. If set the permission to Read only, i can't modify it but it executes. I can also set it to W: and gets: READ_CONTROL, SYNCHRONIZE, FILE_GENERIC_WRITE, FILE_WRITE_DATA, FILE_APPEND_DATA, FILE_WRITE_EA, FILE_EXECUTE, FILE_WRITE_ATTRIBUTES, but i'm not able to change them individually. Am i missing something? Is there another way to modify them apart of cacls? None *.msc nor properties page seem to do it.
they're called text services, Windows supports them since Windows XP and the framework to run them is available for Windows 2000 too
How are they used/programmed? At installed services i only see Language (child> Keyboard (child> Language. Not strange i didn't know.
GvG: "please solve the world's hunger problem and find a cure for cancer too." That'd be great if someone did. Even better than making a free OS windows compatible. And if we're not able to get that goal (yet), why not buy microsoft to free its code?
We can't solve the world's hunger problem, but we can give a windows-like OS to the world. Slogan: 'Use your money to avoid world hunger instead for buying windows.'
-
Alex Ionescu -
Casper Hornstrup -
crashfourit -
David Hinz -
David Johnson -
Ge van Geldorp -
KJKHyperion -
Michael B. Trausch -
Sarocet