Difference between revisions of "Security"

From ReactOS Wiki
Jump to: navigation, search
(Bullet responses about each idea, remove pointless link)
Line 1: Line 1:
[[UserSecurity]]
 
 
 
[[LoginProcess]]
 
[[LoginProcess]]
  
Line 12: Line 10:
  
 
# 2nd stage setup should prompt for administrative password, then prompt (like XP) for user account names, but those user accounts should not be administrator accounts by default.  
 
# 2nd stage setup should prompt for administrative password, then prompt (like XP) for user account names, but those user accounts should not be administrator accounts by default.  
# OK, or offer an option (EG, right below the usrname field have a drop down or radio button selection for the type of usr and default it to Standard Usr). Also allow the system to be setup without any other usr besides the Administ. I HIGHLY dislike being FORCED to create an account in XP only to then have to immediately delete it and use Administrator. [uniQ]  
+
#* OK, or offer an option (EG, right below the usrname field have a drop down or radio button selection for the type of usr and default it to Standard Usr). Also allow the system to be setup without any other usr besides the Administ. I HIGHLY dislike being FORCED to create an account in XP only to then have to immediately delete it and use Administrator. [uniQ]  
# Of course not, nobody was talking about forcing anything upon a user. Just the default should be very security conscious. [Royce3]  
+
#* Of course not, nobody was talking about forcing anything upon a user. Just the default should be very security conscious. [Royce3]  
 
# The default wallpaper/theme for an account with administrative access should be something like what RedHat? has done - something that gets attention and says "Hey! You shouldn't stay logged on like this for long!"  
 
# The default wallpaper/theme for an account with administrative access should be something like what RedHat? has done - something that gets attention and says "Hey! You shouldn't stay logged on like this for long!"  
 
# There should be a pop-up dialog ( akin the "Safe Mode" popup ) indicating that the user has logged on with Administrative rights with an option ( not on by default ) to never see the dialog again ( should be an HKCU setting ). In other words, if you just click Ok, you will see the dialog every time you log in as that user.  
 
# There should be a pop-up dialog ( akin the "Safe Mode" popup ) indicating that the user has logged on with Administrative rights with an option ( not on by default ) to never see the dialog again ( should be an HKCU setting ). In other words, if you just click Ok, you will see the dialog every time you log in as that user.  
# Alright, but the popup/wallpaper should be changable/disableable so someone who wants/needs to login as an/the Administrator can do so without having to field warnings and glaring red wallpaper [uniQ]  
+
#* Alright, but the popup/wallpaper should be changable/disableable so someone who wants/needs to login as an/the Administrator can do so without having to field warnings and glaring red wallpaper [uniQ]  
 
# "Run As" should be very accessible, and available for documents as well as executables. It should be on the Start/Run? dialog by default ( I notice mine is missing?!? ).  
 
# "Run As" should be very accessible, and available for documents as well as executables. It should be on the Start/Run? dialog by default ( I notice mine is missing?!? ).  
# There may be problems in implementing "Run As" for documents. Or better, it needs to be thought of carefully. "Run As" will presumably only apply to the default action: what about the others? what about verbs added by shell extensions? We need some sort of specification, here [KJK::Hyperion]  
+
#* There may be problems in implementing "Run As" for documents. Or better, it needs to be thought of carefully. "Run As" will presumably only apply to the default action: what about the others? what about verbs added by shell extensions? We need some sort of specification, here [KJK::Hyperion]  
# For your Start > Run idea, I envision a checkbox (or radio button) alongwith "Run in seperate memoryspace" called "Run under alternate credentials" or "Run as different user" (If a radbutton, then "Run as current user (%USERNAME%)" or "Run as %USERNAME%" and "Run as different user". When the RunAs? option is selected, the Run box can expand (Or have a "Details >>" or similar option) for the user to fill in the credentials then and there, or have a seperate, system standard login prompt appear. [uniQ]  
+
#* For your Start > Run idea, I envision a checkbox (or radio button) alongwith "Run in seperate memoryspace" called "Run under alternate credentials" or "Run as different user" (If a radbutton, then "Run as current user (%USERNAME%)" or "Run as %USERNAME%" and "Run as different user". When the RunAs? option is selected, the Run box can expand (Or have a "Details >>" or similar option) for the user to fill in the credentials then and there, or have a seperate, system standard login prompt appear. [uniQ]  
# Perhaps we need to refine the idea here. I can see from these comments as well as those below, that the need to run "as" a different user isn't always the optimal solution. Elevating a user's access within a specific context would be, however. Perhaps instead of "Run As" we need an option to temporarily grant this process specific rights not normally available. They can be grouped in logical ways: low-level disk access, raw sockets, total (unencrypted) hard drive access, software installation access, full registry access, installing LSP, BHO, etc... On a side note, certain actions should (by default) require confirmatory password access from the user, like the aforementioned LSP and BHO installation, as well as adding Startup menu entries, or modifying the HKLM(KHCU)/Software/ReactOS Foundation/ReactOS/CurrentVersion/Run set of keys. [Royce3]  
+
#* Perhaps we need to refine the idea here. I can see from these comments as well as those below, that the need to run "as" a different user isn't always the optimal solution. Elevating a user's access within a specific context would be, however. Perhaps instead of "Run As" we need an option to temporarily grant this process specific rights not normally available. They can be grouped in logical ways: low-level disk access, raw sockets, total (unencrypted) hard drive access, software installation access, full registry access, installing LSP, BHO, etc... On a side note, certain actions should (by default) require confirmatory password access from the user, like the aforementioned LSP and BHO installation, as well as adding Startup menu entries, or modifying the HKLM(KHCU)/Software/ReactOS Foundation/ReactOS/CurrentVersion/Run set of keys. [Royce3]  
# Here's my 2 cents worth. I think that the RunAs? for stupid applications should be setup in a way similar to that of KDE or GNOME under Red Hat Linux. If you run a program that requires Administrator/root privs, then have it prompt for the admin/root password. Let's use the Red Hat Update program for instance. If you load that program as a normal user and the program is a part of the system/root group, it pops up a dialog requesting the root password. I know the FAT16/FAT32/NTFS file systems are not designed for such security, but at least with NTFS it could be possible. [jpyper]  
+
#* Here's my 2 cents worth. I think that the RunAs? for stupid applications should be setup in a way similar to that of KDE or GNOME under Red Hat Linux. If you run a program that requires Administrator/root privs, then have it prompt for the admin/root password. Let's use the Red Hat Update program for instance. If you load that program as a normal user and the program is a part of the system/root group, it pops up a dialog requesting the root password. I know the FAT16/FAT32/NTFS file systems are not designed for such security, but at least with NTFS it could be possible. [jpyper]  
 
# (my note - I know this is probably a BAAAAD idea - just throwing it out) We could possibly give the OS the ability to prompt a user for alternative logon credentials in "access denied" scenarios, giving the user the ability to "bump up" their access for the process that is running into the problem.  
 
# (my note - I know this is probably a BAAAAD idea - just throwing it out) We could possibly give the OS the ability to prompt a user for alternative logon credentials in "access denied" scenarios, giving the user the ability to "bump up" their access for the process that is running into the problem.  
# Bad idea. It could get confusing and it may actually break programs. And you'd need complex eurystics to detect which "access denied" errors are expected and which should trigger this behavior. And it doesn't take in account resource managers implementing their own hierarchy of objects with ACLs (much more common than you could think: printer spooler, SAM database, LSA policy, etc.). It's complex, it won't work consistently and if the eurystics fail it will get obnoxious (see the Office assistant). I vote against it [KJK::Hyperion]  
+
#* Bad idea. It could get confusing and it may actually break programs. And you'd need complex eurystics to detect which "access denied" errors are expected and which should trigger this behavior. And it doesn't take in account resource managers implementing their own hierarchy of objects with ACLs (much more common than you could think: printer spooler, SAM database, LSA policy, etc.). It's complex, it won't work consistently and if the eurystics fail it will get obnoxious (see the Office assistant). I vote against it [KJK::Hyperion]  
# This sounds like a case for RunAs?! (Or @least for those savvy enough to use it) (PS. KJK, do you mean heuristics?) [uniQ]  
+
#* This sounds like a case for RunAs?! (Or @least for those savvy enough to use it) (PS. KJK, do you mean heuristics?) [uniQ]  
# It would need to give explicit details on what exactly the process is trying to do, the name of the process, it's window name, and the full path to the executable.  
+
#* It would need to give explicit details on what exactly the process is trying to do, the name of the process, it's window name, and the full path to the executable.  
# The full path of the executable is unreliable, and not terribly useful for whole classes of programs (like script interpreters) [KJK::Hyperion]  
+
#* The full path of the executable is unreliable, and not terribly useful for whole classes of programs (like script interpreters) [KJK::Hyperion]  
# Perhaps this would be useful if applied to specific priviledges only. For example, if possible, we should never prompt the user to upgrade to administrator in order to create raw sockets, or write to the boot sector.  
+
#* Perhaps this would be useful if applied to specific priviledges only. For example, if possible, we should never prompt the user to upgrade to administrator in order to create raw sockets, or write to the boot sector.  
# An extention of the above idea. When a process tries to do something unauthorized/dangerous (Eg. Create raw sockets, write the bootsector, write the registry, add something to startup, integrate with the shell, etc, etc) ROSExp display the full info (name, path (both if it's a script), icon?, action, etc, etc) and have a heuristic "thermomiter" or something similar that gagues the likelihood that it's maliscous (EG. If it's a script, then it's more threatenening then an EXE, if it's running from the temp directory it's more threatening, if anything is trying to create raw UDP sockets then it's automatically a high-ish risk))  
+
## An extention of the above idea. When a process tries to do something unauthorized/dangerous (Eg. Create raw sockets, write the bootsector, write the registry, add something to startup, integrate with the shell, etc, etc) ROSExp display the full info (name, path (both if it's a script), icon?, action, etc, etc) and have a heuristic "thermomiter" or something similar that gagues the likelihood that it's maliscous (EG. If it's a script, then it's more threatenening then an EXE, if it's running from the temp directory it's more threatening, if anything is trying to create raw UDP sockets then it's automatically a high-ish risk))  
 
# There should be a registry entry ( editable from a tab in file-properties ) indicating if Windows should always give the user the option to "Run As" for that executable. For example, mmc.exe should automatically prompt if the user isn't already Administrator.  
 
# There should be a registry entry ( editable from a tab in file-properties ) indicating if Windows should always give the user the option to "Run As" for that executable. For example, mmc.exe should automatically prompt if the user isn't already Administrator.  
# No, it shouldn't. There are many MMC tasks that are meant to be performed by any user [KJK::Hyperion]  
+
#* No, it shouldn't. There are many MMC tasks that are meant to be performed by any user [KJK::Hyperion]  
# Even if MMC is a bad example, it's still a valid idea [uniQ]  
+
#* Even if MMC is a bad example, it's still a valid idea [uniQ]  
# True, please see my comment above... we need to give the user the ability to "elevate" his/her priviledges temporarily within a specific context, not actually change what user the program is running "as". Being able to temporarily elevate certain rights within a specific context/process is far more useful. [Royce3]  
+
#* True, please see my comment above... we need to give the user the ability to "elevate" his/her priviledges temporarily within a specific context, not actually change what user the program is running "as". Being able to temporarily elevate certain rights within a specific context/process is far more useful. [Royce3]  
# Certain executables should be configured by default, like "setup.exe", as well as applications that are known to not work in XP's "Limited User" mode, like Quicken 2000, etc.  
+
#* Certain executables should be configured by default, like "setup.exe", as well as applications that are known to not work in XP's "Limited User" mode, like Quicken 2000, etc.  
# Running stupid applications with administrator privileges? no, thanks (you would even get the "wrong" user profile, causing anger and embarassment). I'd like a better solution. Oh, and you should have a look at the application compatibility framework in Windows: pretty sophisticated rules to identify programs, and some of the fixes do amazing things. A must-have to keep the core DLLs clean and support stupid applications at the same time [KJK::Hyperion]  
+
#* Running stupid applications with administrator privileges? no, thanks (you would even get the "wrong" user profile, causing anger and embarassment). I'd like a better solution. Oh, and you should have a look at the application compatibility framework in Windows: pretty sophisticated rules to identify programs, and some of the fixes do amazing things. A must-have to keep the core DLLs clean and support stupid applications at the same time [KJK::Hyperion]  
# Correct, which is why we need to elevate the current user's priviledges, not run as a different user. [Royce3]  
+
#* Correct, which is why we need to elevate the current user's priviledges, not run as a different user. [Royce3]  
 
# "Run As" passwords should not be cacheable by any means provided by ReactOS.  
 
# "Run As" passwords should not be cacheable by any means provided by ReactOS.  
# Personal opinion ("matter of taste"): obnoxious. It shouldn't be outright impossible [KJK::Hyperion]  
+
#* Personal opinion ("matter of taste"): obnoxious. It shouldn't be outright impossible [KJK::Hyperion]  
# RunAs? passwds are (On Windows @least (I beleive)) are login passwords. So if someone logged on as a normal user has an Administ come by and 'RunAs?' something to install it, they can then possibly recover the Administs passwd. Hence not caching passwords is a good idea. However I could see an option somewhere to allow caching and the # to cache (And whether or not to cache Adminsts, whether or not to cache passwds of users with greater privliges) [uniQ]  
+
#* RunAs? passwds are (On Windows @least (I beleive)) are login passwords. So if someone logged on as a normal user has an Administ come by and 'RunAs?' something to install it, they can then possibly recover the Administs passwd. Hence not caching passwords is a good idea. However I could see an option somewhere to allow caching and the # to cache (And whether or not to cache Adminsts, whether or not to cache passwds of users with greater privliges) [uniQ]  
# A user should be required to have a password for an account with the priviledges he/she's trying to attach to the current process, but the process should still run "as" the current user - just with elevated priviledges. As far as being obnoxious... at first I was going to argue, but practically speaking you are correct :( [Royce3] ( Obviously a savvy programmer could provide a gator-esque utility to do this, but it would be a stupid thing to do - perhaps there are mechanisms we could employ to detect automatic form entry and defeat it - like adding some random data to the windows' title or even do an "access denied" when attempting to get the window's title if possible, randomizing the class name, the control ids, disabling paste, etc...  
+
#* A user should be required to have a password for an account with the priviledges he/she's trying to attach to the current process, but the process should still run "as" the current user - just with elevated priviledges. As far as being obnoxious... at first I was going to argue, but practically speaking you are correct :( [Royce3] ( Obviously a savvy programmer could provide a gator-esque utility to do this, but it would be a stupid thing to do - perhaps there are mechanisms we could employ to detect automatic form entry and defeat it - like adding some random data to the windows' title or even do an "access denied" when attempting to get the window's title if possible, randomizing the class name, the control ids, disabling paste, etc...  
# running as a "limited" user is going to result in a mix of "limited" and "admin" windows on your desktop. A "limited" process should have extremely limited access to information about a "admin" process, including information like the caption and contents of any windows the "admin" process owns. This is likely to break some applications, but not most, so I think it would be a good thing. Good idea. Maybe having the usrname on all the windows when RunAs? is invoked 1ce? Or using RunAs? on different desktops! ROS has that desktop switcher, so when it becomes functional, could it be possible to appropriate 1 for RunAsing?? Maybe letting the usr to have both desktops windows visible @ once, then letting them disappear one usr (The Administ one) with all it's open windows and apps? [uniQ]  
+
# running as a "limited" user is going to result in a mix of "limited" and "admin" windows on your desktop. A "limited" process should have extremely limited access to information about a "admin" process, including information like the caption and contents of any windows the "admin" process owns. This is likely to break some applications, but not most, so I think it would be a good thing.
# Ability to 'su' to admin from the command prompt [Gedi] - this alrady exist in Windows 2000/XP Pro. called 'runas' [pentiumforever]
+
#*Good idea. Maybe having the usrname on all the windows when RunAs? is invoked 1ce? Or using RunAs? on different desktops! ROS has that desktop switcher, so when it becomes functional, could it be possible to appropriate 1 for RunAsing?? Maybe letting the usr to have both desktops windows visible @ once, then letting them disappear one usr (The Administ one) with all it's open windows and apps? [uniQ]  
 +
# Ability to 'su' to admin from the command prompt [Gedi]
 +
#* this alrady exist in Windows 2000/XP Pro. called 'runas' [pentiumforever]
 
# Inclusion of a simple [[Firewall]] which defaults to 'on' upon OS instalation. [Gedi]
 
# Inclusion of a simple [[Firewall]] which defaults to 'on' upon OS instalation. [Gedi]
 
# (while login as admin) a special desktop with restricted permission (guest account) for internet applications [frik85]
 
# (while login as admin) a special desktop with restricted permission (guest account) for internet applications [frik85]
## With the ability to disable somewhere and acheive normal functionality [uniQ]
+
#* With the ability to disable somewhere and acheive normal functionality [uniQ]
 
# Programs should be prevented from accessing information of other running threads/windows as much as possible. Exceptions would be the shell and taskmanager.
 
# Programs should be prevented from accessing information of other running threads/windows as much as possible. Exceptions would be the shell and taskmanager.

Revision as of 22:58, 21 November 2009

LoginProcess

ShutdownProcess

Firewall

One area where we need to be compatible, yet differentiate ourselves from Windows (TM) is the area of user security. Here are some thoughts I (Royce3) have had recently on the issue:


  1. 2nd stage setup should prompt for administrative password, then prompt (like XP) for user account names, but those user accounts should not be administrator accounts by default.
    • OK, or offer an option (EG, right below the usrname field have a drop down or radio button selection for the type of usr and default it to Standard Usr). Also allow the system to be setup without any other usr besides the Administ. I HIGHLY dislike being FORCED to create an account in XP only to then have to immediately delete it and use Administrator. [uniQ]
    • Of course not, nobody was talking about forcing anything upon a user. Just the default should be very security conscious. [Royce3]
  2. The default wallpaper/theme for an account with administrative access should be something like what RedHat? has done - something that gets attention and says "Hey! You shouldn't stay logged on like this for long!"
  3. There should be a pop-up dialog ( akin the "Safe Mode" popup ) indicating that the user has logged on with Administrative rights with an option ( not on by default ) to never see the dialog again ( should be an HKCU setting ). In other words, if you just click Ok, you will see the dialog every time you log in as that user.
    • Alright, but the popup/wallpaper should be changable/disableable so someone who wants/needs to login as an/the Administrator can do so without having to field warnings and glaring red wallpaper [uniQ]
  4. "Run As" should be very accessible, and available for documents as well as executables. It should be on the Start/Run? dialog by default ( I notice mine is missing?!? ).
    • There may be problems in implementing "Run As" for documents. Or better, it needs to be thought of carefully. "Run As" will presumably only apply to the default action: what about the others? what about verbs added by shell extensions? We need some sort of specification, here [KJK::Hyperion]
    • For your Start > Run idea, I envision a checkbox (or radio button) alongwith "Run in seperate memoryspace" called "Run under alternate credentials" or "Run as different user" (If a radbutton, then "Run as current user (%USERNAME%)" or "Run as %USERNAME%" and "Run as different user". When the RunAs? option is selected, the Run box can expand (Or have a "Details >>" or similar option) for the user to fill in the credentials then and there, or have a seperate, system standard login prompt appear. [uniQ]
    • Perhaps we need to refine the idea here. I can see from these comments as well as those below, that the need to run "as" a different user isn't always the optimal solution. Elevating a user's access within a specific context would be, however. Perhaps instead of "Run As" we need an option to temporarily grant this process specific rights not normally available. They can be grouped in logical ways: low-level disk access, raw sockets, total (unencrypted) hard drive access, software installation access, full registry access, installing LSP, BHO, etc... On a side note, certain actions should (by default) require confirmatory password access from the user, like the aforementioned LSP and BHO installation, as well as adding Startup menu entries, or modifying the HKLM(KHCU)/Software/ReactOS Foundation/ReactOS/CurrentVersion/Run set of keys. [Royce3]
    • Here's my 2 cents worth. I think that the RunAs? for stupid applications should be setup in a way similar to that of KDE or GNOME under Red Hat Linux. If you run a program that requires Administrator/root privs, then have it prompt for the admin/root password. Let's use the Red Hat Update program for instance. If you load that program as a normal user and the program is a part of the system/root group, it pops up a dialog requesting the root password. I know the FAT16/FAT32/NTFS file systems are not designed for such security, but at least with NTFS it could be possible. [jpyper]
  5. (my note - I know this is probably a BAAAAD idea - just throwing it out) We could possibly give the OS the ability to prompt a user for alternative logon credentials in "access denied" scenarios, giving the user the ability to "bump up" their access for the process that is running into the problem.
    • Bad idea. It could get confusing and it may actually break programs. And you'd need complex eurystics to detect which "access denied" errors are expected and which should trigger this behavior. And it doesn't take in account resource managers implementing their own hierarchy of objects with ACLs (much more common than you could think: printer spooler, SAM database, LSA policy, etc.). It's complex, it won't work consistently and if the eurystics fail it will get obnoxious (see the Office assistant). I vote against it [KJK::Hyperion]
    • This sounds like a case for RunAs?! (Or @least for those savvy enough to use it) (PS. KJK, do you mean heuristics?) [uniQ]
    • It would need to give explicit details on what exactly the process is trying to do, the name of the process, it's window name, and the full path to the executable.
    • The full path of the executable is unreliable, and not terribly useful for whole classes of programs (like script interpreters) [KJK::Hyperion]
    • Perhaps this would be useful if applied to specific priviledges only. For example, if possible, we should never prompt the user to upgrade to administrator in order to create raw sockets, or write to the boot sector.
    1. An extention of the above idea. When a process tries to do something unauthorized/dangerous (Eg. Create raw sockets, write the bootsector, write the registry, add something to startup, integrate with the shell, etc, etc) ROSExp display the full info (name, path (both if it's a script), icon?, action, etc, etc) and have a heuristic "thermomiter" or something similar that gagues the likelihood that it's maliscous (EG. If it's a script, then it's more threatenening then an EXE, if it's running from the temp directory it's more threatening, if anything is trying to create raw UDP sockets then it's automatically a high-ish risk))
  6. There should be a registry entry ( editable from a tab in file-properties ) indicating if Windows should always give the user the option to "Run As" for that executable. For example, mmc.exe should automatically prompt if the user isn't already Administrator.
    • No, it shouldn't. There are many MMC tasks that are meant to be performed by any user [KJK::Hyperion]
    • Even if MMC is a bad example, it's still a valid idea [uniQ]
    • True, please see my comment above... we need to give the user the ability to "elevate" his/her priviledges temporarily within a specific context, not actually change what user the program is running "as". Being able to temporarily elevate certain rights within a specific context/process is far more useful. [Royce3]
    • Certain executables should be configured by default, like "setup.exe", as well as applications that are known to not work in XP's "Limited User" mode, like Quicken 2000, etc.
    • Running stupid applications with administrator privileges? no, thanks (you would even get the "wrong" user profile, causing anger and embarassment). I'd like a better solution. Oh, and you should have a look at the application compatibility framework in Windows: pretty sophisticated rules to identify programs, and some of the fixes do amazing things. A must-have to keep the core DLLs clean and support stupid applications at the same time [KJK::Hyperion]
    • Correct, which is why we need to elevate the current user's priviledges, not run as a different user. [Royce3]
  7. "Run As" passwords should not be cacheable by any means provided by ReactOS.
    • Personal opinion ("matter of taste"): obnoxious. It shouldn't be outright impossible [KJK::Hyperion]
    • RunAs? passwds are (On Windows @least (I beleive)) are login passwords. So if someone logged on as a normal user has an Administ come by and 'RunAs?' something to install it, they can then possibly recover the Administs passwd. Hence not caching passwords is a good idea. However I could see an option somewhere to allow caching and the # to cache (And whether or not to cache Adminsts, whether or not to cache passwds of users with greater privliges) [uniQ]
    • A user should be required to have a password for an account with the priviledges he/she's trying to attach to the current process, but the process should still run "as" the current user - just with elevated priviledges. As far as being obnoxious... at first I was going to argue, but practically speaking you are correct :( [Royce3] ( Obviously a savvy programmer could provide a gator-esque utility to do this, but it would be a stupid thing to do - perhaps there are mechanisms we could employ to detect automatic form entry and defeat it - like adding some random data to the windows' title or even do an "access denied" when attempting to get the window's title if possible, randomizing the class name, the control ids, disabling paste, etc...
  8. running as a "limited" user is going to result in a mix of "limited" and "admin" windows on your desktop. A "limited" process should have extremely limited access to information about a "admin" process, including information like the caption and contents of any windows the "admin" process owns. This is likely to break some applications, but not most, so I think it would be a good thing.
    • Good idea. Maybe having the usrname on all the windows when RunAs? is invoked 1ce? Or using RunAs? on different desktops! ROS has that desktop switcher, so when it becomes functional, could it be possible to appropriate 1 for RunAsing?? Maybe letting the usr to have both desktops windows visible @ once, then letting them disappear one usr (The Administ one) with all it's open windows and apps? [uniQ]
  9. Ability to 'su' to admin from the command prompt [Gedi]
    • this alrady exist in Windows 2000/XP Pro. called 'runas' [pentiumforever]
  10. Inclusion of a simple Firewall which defaults to 'on' upon OS instalation. [Gedi]
  11. (while login as admin) a special desktop with restricted permission (guest account) for internet applications [frik85]
    • With the ability to disable somewhere and acheive normal functionality [uniQ]
  12. Programs should be prevented from accessing information of other running threads/windows as much as possible. Exceptions would be the shell and taskmanager.