[ros-kernel] User Security

[Eric Kohl]

"Jonathan Wilson" <jonwil at tpgi.com.au> wrote:


> Some thoughts:
> 1.a bunch of "risky" events should be locked so that you need to be
running
>   as admin and/or input a password before you can do them.
> These include:
> Adding a program to any of the "start this program at startup" lists
> Loading a driver (certainly installing a driver and configuring it to load
> automatically at windows startup)
> Changing various important system settings
> Changing or attempting to change operating system files
> And perhaps there are other "security risks"

ReactOS will support these features! Some of them are implemented by the use
of certain privileges (= right to perform a particular action) and others
are implemented by access rights to the object tree, registry and
filesystems.


> Together, these options would make windows more secure (since you dont
need
> to run administrator just to play games and stuff and also because the
> avenues used by viruses, spyware and malware to get into your system are
> locked such that if a program tries to use them, at least you get a
warning.

The main issue is not the lack of security features but the inability of
some appications, or their developers, to obey to the security concepts of
Windows. For example, no application should ever install files in the system
directories, not even MS Office. Trying to get such badly written
applications running is like cutting a hole into a vault in order to enable
people to put things into the vault without the need for a key; you'd only
need a key to remove something from the vault. :-/


> Something like "c:\windows\temp\~1a324fed\asdrfdyter.exe" wishes to
> overwrite c:\windows\system32\kernel32.dll with
> c:\windows\temp\~1a324fed\virus.dll, if you want this to happen, enter the
> administrator password now".

You won't gain any security by such a warning because the use must know
whether a file is ok or contains malicious code. Virus.dll is an obvious
name but a malware writer with a decent IQ will obviously try to replace the
original kernel32.dll by a hacked kernel32.dll. How do you want to protect
the user from such an attempt? The answer is simple: No user can write to a
system directory! Only the administrator is able to update system files.


Regards,
Eric