Security Suite

[David Hinz]

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

[David Johnson]

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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  


--
David Johnson
http://www.davefilms.us

[Sarocet]

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.

[crashfourit]

I would say that that is a good idea.

On 11/16/05, Sarocet <Sarocet(a)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(a)gmail.com>
>  *To:* ReactOS Development List <ros-dev(a)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(a)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/

[KJKHyperion]

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

[Michael B. Trausch]

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

-- 
Michael B. Trausch                                      fd0man(a)gmail.com
AIM: MB Trausch                             Jabber:  mtrausch(a)jabber.com

[Sarocet]

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(a)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

[Casper Hornstrup]

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(a)reactos.org [mailto:[e-mail]] 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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Sarocet]

----- Original Message ----- 
From: "Casper Hornstrup" ch(a)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.

[Michael B. Trausch]

[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

-- 
Michael B. Trausch                                      fd0man(a)gmail.com
AIM: MB Trausch                             Jabber:  mtrausch(a)jabber.com

[KJKHyperion]

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

[David Johnson]

Make it happen.

On 11/19/05, KJKHyperion <hackbunny(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  


--
David Johnson
http://www.davefilms.us

[Ge van Geldorp]

And while you're at it, please solve the world's hunger problem and find a
cure for cancer too.


  _____  

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] 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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev





-- 
David Johnson
http://www.davefilms.us  <http://www.davefilms.us>

[Alex Ionescu]

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

[David Johnson]

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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  

--
David Johnson
http://www.davefilms.us

[Sarocet]

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.'