Playing the stock market is like every other form of gambling: The house always wins. You lose.
I do not believe that I have seen such a completely misleading and or misinformed statement in a very long time. If you have no idea what you are doing, yeah, you could get burned. If you are smart, do your research and invest wisely, such as by diversifying, you can come out pretty darn well.
This should be done to wash out the concept of complexity will confuse the user. Gnome would benefit from this because it would open up the door to allow users to choose for themselves.
Perhaps, what they could do is provide a pop-up at first login and ask the user what kind of computer user they are:
Super Advanced, Linux h4k3R
Average, Ex-Windows Admin
n00b, newbie...and then configure itself accordingly. (Obviously, the above list is partly for laughs it shouldn't be quite that snarky.)
The Advanced users can get all the functionality they want, similar to KDE, the Average user can have what they need and the Newbie can have the hobbled hand-holding version of GNOME. At a later time, the user can choose to "Activate" the more complex features.
The CU (Combat Upgrade) lead to calls for Pre-CU servers, but that never happened and never will happen as SOE (Sony Online Entertainment) isn't interested in making pre-CU Servers available.
You have repeatedly said that parts of IE run with system privledges, and that subverting IE will enable to you to run code with those privledges. This is *not* true. Subverting IE *may* allow you to execute a local privledge escalation attack, but that is not (at all) the same thing that you have been saying.
Where did I say that? I did say that certain components could be subverted to allow the execution of attacks to subvert the system. Never did I come out and say "IE IS THE CORE AND HEART OF WINDOWS!!!"
That would be stupid and infantile.
Do you have anything to show regarding where your angle is regarding the inherent weakness of the user/group security system in traditional UNIX?
It is logical to assume they will implement this across their server products as soon as possible.
Nobody likes downtime on servers, period, especially from forced reboots.
Testing it on less critical systems, such as home and desktop workstations also seems to be quite logical, since it won't cause undue negative impact on servers while they work out any issues related to this new technology....and I only correct others when they limit themselves or ignore obvious reasons for certain technology developments.
The ability to run under multiple simultaneous user contexts is the important part of being multi-user, it's what has defined Unix, and NT has had the ability forever. The decision by MS to integrate the graphical interface at a low level has limited Windows ability to serve up a GUI to multiple users until recently, but it's been able to provide other (non-GUI) services to multiple users (such as file sharing, or command line logons) for a long time.
That is partially what I was referring to. Until Windows Server 2003, the real multi-user capability of Windows hasn't really existed. (Unless you count some of the interesting 3rd Party setups that allowed two users to work on one Windows 9x workstation at the same time, crazy and slow, stuff that was.) Multi-User meaning providing access to all resources, including full GUI access, to multiple users at the same time.
ACLs are inherently far more flexible and powerful that group based permissions, exspecially group based permissions with a superuser. This is well known and has been for decades, and is why the concept of ACLs was invented in the first place. The traditional unix user/group security model is weak, inflexible, and simple, and while it's a hell of a lot better than no security at all, ACLs are much more powerful. I don't think that any out there claims that Windows had ACLs first (because that would be both stupid and wrong).
Please provide details, links or otherwise detailing the weak, inflexible nature of the traditional user/group security model. I would like to know what angle you are coming from.
I know that ACLs are more powerful and I agree that is why they were developed in the early 90's, for UNIX systems.
Wrong wrong wrong wrong wrong. There is no "IE service" and IE doesn't get any special privledges. IE can be used as a vector for other compromises (certainly via ActiveX, which was a terrible idea), but it's got nothing to do with special IE components and magical access rights.
Are you High?
The "special IE components and Magical Access rights" you suggest I was talking about was ActiveX, which you agree is a terrible idea. I even mentioned ActiveX as the problem child.
I am not doing that. I am just suggesting that there are times when a server will take longer then 17 seconds to reboot and that this new feature is a very useful thing to be added to the system.
...Managers" for a very long time. They are usually hairy, sometimes suffer from poor hygeine or halitosis or stinky feat syndrome. Sometimes they are cranky and short-tempered, but fill them with enough pizza, Mountain Dew and Coffee and they usually work things right.
It takes longer then 17 seconds to reboot a server buddy boy.
It can take longer then 17 seconds just to load up a Database server. Being able to update without a reboot can save a company from potentially missing out of hundreds to thousands of transactions, as people click "Buy now" and are told, "We are currently updating our systems, please come back in approximately 30 minutes."
What planet are you from? World of Yesteryearland?
There's tons of GUI applications to shutdown and restart services on UNIX these days. Plus, some package managers are smart enough to shutdown a service, apply the updated files, copy over the settings, if some configuration files have been altered and then restart the service.
ALL FROM A GUI!
Again, welcome to the world of the future Mr. MS Apologist.
I know perfectly well what multiuser means (although that definition you linked to is terrible), and Windows NT meets (and always has met) the requirements.
No, it hasn't always met those requirements. It has always met what Microsoft has claimed to be "Multi-User". They didn't invent the term, they just applied a brand new meaning to the term and people, like yourself, buy it as the "only" definition that matters.
It's important to understand the "user" part of "multiuser" doesn't refer to actual people. The ability to host multiple interactive sessions doesn't make an OS multiuser (otherwise OS/2 running a BBS server would be considered multiuser) any more than the lack of doing so makes an OS not multiuser (else a unix workstation with only one person in front of it wouldn't be multiuser).
That's Microsoft's new definition talking, once again. When the term was developed, it meant the capability of the OS/System to serve multiple actual people simultaneously. You get an "A" for sticking to the party line, but you should study more of the history of computing.
I say NT is "more multiuser" because access to just about everything in the OS is based around per-user ACLs. (Traditional) Unix, OTOH, only really has two different user contexts at its core - root and "not root" (this is why you *have* to be root to perform certain actions and so many applications use the clumsy hack of starting as root and then "dropping" to a regular user context). User groups are also used to further divide the "not root" aspect and access restrictions to resources are typically implemented by hacking some presentation layer together that looks like a filesystem, but fundamentally it's a primitive system that can't deliver fine-grained permissions.
It sounds like you haven't really spent anytime studying permission control on UNIX. With groups, it is entirely possible to create controls with nested layers of access. I use that all the time. There just hasn't been a need to implement ACLs on the business servers that I am running right now, there's no benefit to implementing that at this time.
However, if you are so uppity about ACLs, just check this. It is the command listing for Solaris 2.5's ACL system, released in 1995. It's UNIX and it had ACL's in 1995. Oh, I bet you didn't know that.
What are you talking about ?
Create a shortcut to the "Add/Remove Programs" control panel applet. Make sure you do this as an unprivileged user. Right-click and click on the "RunAs"... oh wait, it's not there. Hmm... Seems like you have to login with an Administrative account to "Add/Remove" programs from your system. That is an important, yet missing feature of the "RunAs" command. (I thought you knew Windows.)
You know why it is like that? I am taking an educated guess here, but having attempted to run installs after creating a shortcut and then using "RunAs" on the installer shortcut. I believe that "RunAs" only works for the initial application being called, it's not capable of spawning off sub-processes under the elevated privileges the application inherits from the initial "RunAs" activation.
Granted, there is a bit of security in doing so, at the same time, there's no reason that these sub-processes couldn't be ran in a sandbox under the control of the first process, similar to how UNIX handles parent and child processes. It could be written to make "RunAs" the primary process with ALL of the processes called by "RunAs" as subprocesses off of the parent. Thus, all processes spawned from child processes of the "RunAs" process are subservient to "RunAs". When "RunAs" is done with its job, all of the child processes would thus also be done as well.
See, with UNIX I can open up a shell, su to root and then open up an application. Unless I specifically choose to (with a flag), that application w
Your first statement shows how very little you actually know and understand about the architecture of Operating Systems.
Your second statement shows how very little you understand about how the Windows GUI functions and how it is possible to root a Windows machine, based upon the fundamental flaws in the methods that the Windows GUI uses to pass messages to other windows and backgruond processes on a given workstation. There was a proof of concept attack developed a little over a year ago, based upon years of research and regular complaints about the inherent, impossible to fix, problem with MS Windows internal messaging system. Look up the 'shatter' attack.
Your third statement shows how very little you understand about the UNIX and Linux security model and also the real difference in numbers between UNIX/Linux 'root' exploits and the numbers of Kernel Level exploits that are possible on Windows machines.
Your fourth statement is partially correct. Sure, Application vendors have continued to code applications that require more system access then may well be necesary, but that's also because many of those applications follow Microsoft's own development guidelines and attempt to use and reuse DLLs that exist on a given Windows installation.
Your last statement is close to what should be done. Microsoft should simply say, "F-it" and screw backwards compatibility for native Vista/XP/2003 applications. They should provide a free and automatic Virtual Machine environment to effectively sandbox all the older applications so that those applications have the "access" they require while still holding the security integrity of the machine in a high protection state.
Windows is a multiuser OS. *More* so than the typical unix, if anything, with it's fine grained per-user ACLs in just about every aspect of the OS.
Okay, now you are smoking something. Why don't you look up Multi-User and understand that Windows still isn't as Multi-User as UNIX is. Sure, the latest versions of Windows Server 2003 do allow multiple users to access a GUi simultaneously, but that development is still quite in it's infancy compared to the 30+ years of UNIX performing that quite admirably.
This is an application problem, not an OS problem.
An application program with components that ship with the operating system from the operating system vendor. So, I suppose that is sort of right, (If you want to be very obtuse about it) of course under UNIX you don't have those problems when using sudo or su into root and then running an application.
Yes, SYSTEM is about as close as you get on Windows to 'root' on unix. What's your point ?
The point is that if a malicious application elevates itself to "SYSTEM" level privileges, the only recourse is to wipe the machine completely. You are effectively 'rooted' and there is no method of truly protecting that level of the OS as an Administrator, since you are effectively cut out from it.
Bravo. I couldn't have said it better myself. (Mostly because I didn't have the time to look that proof of concept way of smashing through Windows security via an unprivileged user account.)
If it isn't integrated into the OS, please open up your "Program Files" directory, right-click on the "Internet Explorer" folder and delete it from your hard drive. You should have no problem in doing this and your computer should experience no problems.
The only problems you might experience would be the loss of a "default" web browser that you would need to reset. (If it isn't integrated into the OS.)
Please post your results.
Remember the big court case against Microsoft a handful of years back? Microsoft claimed time and time again that they couldn't remove Internet Explorer, because THEY HAD INTEGRATED IT INTO THE OS. How could that fact be considered an opinion when Microsoft entered it as FACT in the court case where they were found to be abusing their monopoly status?
The UNIX sudo can also be set to allow only particular users to run it, instead of letting everyone on a given system use the sudo command.
It's not the command that is superior, so much as the underlying security model that allows a user to elevate their privileges temporarily to run any application, from installing to major setting changes. The Windows "RunAs" guffaws at installing applications(that require and admin account), using "Administrator" in the "RunAs" window, while logged in as an unprivileged user.
IE exploits can change SYSTEM binaries and libraries. If it was a "User Space" application, instead of something else, it wouldn't be able to do that.
I have had users, that I specifically setup as unprivileged, find their way onto the Internet with IE and completely hose the system. Tell me how an unprivileged user, running a web browser, should be capable of diong that?
If IE wasn't integrated into the OS in some way beyond being a simple "User Space" application, then it wouldn't have been possible for them to do what they did. Also, if it wasn't integrated into the OS, I should be able to right-click and delete the IE directory without detrimental effect, beyond simply needing to address what the default web browser on the system is.
Since you are so sure it isn't integrated into the OS, why don't you open up your program files directory and simply delete IE off the PC and then go about your business. Please, post your results.
You just answered that yourself. You see "System Binaries" should never be alterable/replaceable by a "User Space" application. Web Browsers are supposed to be purely "User Space" applications, but IE isn't held to that standard, hence the ability t "root" a Windows machine directly through the Internet Explorer web browser.
The statement "security cannot be retro-fitted to a system" holds very true.
That's why UNIX is very comparmentalized and each component isn't tightly integrated with each and every other component on the system. This means when you are "retro-fitting" a subsystem of UNIX you aren't changing the ENTIRE OS, just that one piece, which is significantly easier then trying to patch a security hole in a massive pile of integrated code, like MS Windows is.
The evidence of the problems with the the Windows development model is showcased in that virtually every single flaw exploited has almost always resulted in a total compromise of the system, not just a compromise of one subsystem giving the attacker limited access to the total system.
As you are a Home User, I won't knock you for not understanding the true difference between what an effective User-Level and Multi-User OS is and what MS has provided.
While they have made major leaps forward, with the "RunAs" feature, there are still significant applications that cannot be run using the "RunAs" feature. It only goes so far.
Then, there is the SYSTEM group. This "Group" is controlled by the computer itself and if an application good or bad, runs under the SYSTEM level privileges, there is no method for even an administrator of the machine to kill or otherwise control what is going on, without rebooting/rebuilding the OS.
Effectively, you do not "control" or have "full control" as an available option on a Windows machine and at best, you have Ring 1 access and never Ring 0 access to the OS and its internals.
Slashdot Mirror
I do not believe that I have seen such a completely misleading and or misinformed statement in a very long time. If you have no idea what you are doing, yeah, you could get burned. If you are smart, do your research and invest wisely, such as by diversifying, you can come out pretty darn well.
Seriously, what is GIMP, besides "GNU Image Manipulation Program"?
What GNOME needs is an enema.
...and then configure itself accordingly. (Obviously, the above list is partly for laughs it shouldn't be quite that snarky.)
This should be done to wash out the concept of complexity will confuse the user. Gnome would benefit from this because it would open up the door to allow users to choose for themselves.
Perhaps, what they could do is provide a pop-up at first login and ask the user what kind of computer user they are:
Super Advanced, Linux h4k3R
Average, Ex-Windows Admin
n00b, newbie
The Advanced users can get all the functionality they want, similar to KDE, the Average user can have what they need and the Newbie can have the hobbled hand-holding version of GNOME. At a later time, the user can choose to "Activate" the more complex features.
If they did this, then I might consider GNOME.
The CU (Combat Upgrade) lead to calls for Pre-CU servers, but that never happened and never will happen as SOE (Sony Online Entertainment) isn't interested in making pre-CU Servers available.
The rest is accurate.
Where did I say that? I did say that certain components could be subverted to allow the execution of attacks to subvert the system. Never did I come out and say "IE IS THE CORE AND HEART OF WINDOWS!!!"
That would be stupid and infantile.
Do you have anything to show regarding where your angle is regarding the inherent weakness of the user/group security system in traditional UNIX?
It is logical to assume they will implement this across their server products as soon as possible.
...and I only correct others when they limit themselves or ignore obvious reasons for certain technology developments.
Nobody likes downtime on servers, period, especially from forced reboots.
Testing it on less critical systems, such as home and desktop workstations also seems to be quite logical, since it won't cause undue negative impact on servers while they work out any issues related to this new technology.
That is partially what I was referring to. Until Windows Server 2003, the real multi-user capability of Windows hasn't really existed. (Unless you count some of the interesting 3rd Party setups that allowed two users to work on one Windows 9x workstation at the same time, crazy and slow, stuff that was.) Multi-User meaning providing access to all resources, including full GUI access, to multiple users at the same time.
ACLs are inherently far more flexible and powerful that group based permissions, exspecially group based permissions with a superuser. This is well known and has been for decades, and is why the concept of ACLs was invented in the first place. The traditional unix user/group security model is weak, inflexible, and simple, and while it's a hell of a lot better than no security at all, ACLs are much more powerful. I don't think that any out there claims that Windows had ACLs first (because that would be both stupid and wrong).
Please provide details, links or otherwise detailing the weak, inflexible nature of the traditional user/group security model. I would like to know what angle you are coming from.
I know that ACLs are more powerful and I agree that is why they were developed in the early 90's, for UNIX systems.
Wrong wrong wrong wrong wrong. There is no "IE service" and IE doesn't get any special privledges. IE can be used as a vector for other compromises (certainly via ActiveX, which was a terrible idea), but it's got nothing to do with special IE components and magical access rights.
Are you High?
The "special IE components and Magical Access rights" you suggest I was talking about was ActiveX, which you agree is a terrible idea. I even mentioned ActiveX as the problem child.
I am not doing that. I am just suggesting that there are times when a server will take longer then 17 seconds to reboot and that this new feature is a very useful thing to be added to the system.
They are typically called System Administrators.
It takes longer then 17 seconds to reboot a server buddy boy.
It can take longer then 17 seconds just to load up a Database server. Being able to update without a reboot can save a company from potentially missing out of hundreds to thousands of transactions, as people click "Buy now" and are told, "We are currently updating our systems, please come back in approximately 30 minutes."
Would you? I wouldn't.
What planet are you from? World of Yesteryearland?
There's tons of GUI applications to shutdown and restart services on UNIX these days. Plus, some package managers are smart enough to shutdown a service, apply the updated files, copy over the settings, if some configuration files have been altered and then restart the service.
ALL FROM A GUI!
Again, welcome to the world of the future Mr. MS Apologist.
HP-UX had ACLs back in 1992.
See This
At the same time. Windows didn't get ACLs until 1996 with the release of Windows NT 4.0, see below.
Windows ACL
No, it hasn't always met those requirements. It has always met what Microsoft has claimed to be "Multi-User". They didn't invent the term, they just applied a brand new meaning to the term and people, like yourself, buy it as the "only" definition that matters.
It's important to understand the "user" part of "multiuser" doesn't refer to actual people. The ability to host multiple interactive sessions doesn't make an OS multiuser (otherwise OS/2 running a BBS server would be considered multiuser) any more than the lack of doing so makes an OS not multiuser (else a unix workstation with only one person in front of it wouldn't be multiuser).
That's Microsoft's new definition talking, once again. When the term was developed, it meant the capability of the OS/System to serve multiple actual people simultaneously. You get an "A" for sticking to the party line, but you should study more of the history of computing.
I say NT is "more multiuser" because access to just about everything in the OS is based around per-user ACLs. (Traditional) Unix, OTOH, only really has two different user contexts at its core - root and "not root" (this is why you *have* to be root to perform certain actions and so many applications use the clumsy hack of starting as root and then "dropping" to a regular user context). User groups are also used to further divide the "not root" aspect and access restrictions to resources are typically implemented by hacking some presentation layer together that looks like a filesystem, but fundamentally it's a primitive system that can't deliver fine-grained permissions.
It sounds like you haven't really spent anytime studying permission control on UNIX. With groups, it is entirely possible to create controls with nested layers of access. I use that all the time. There just hasn't been a need to implement ACLs on the business servers that I am running right now, there's no benefit to implementing that at this time.
However, if you are so uppity about ACLs, just check this. It is the command listing for Solaris 2.5's ACL system, released in 1995. It's UNIX and it had ACL's in 1995. Oh, I bet you didn't know that.
What are you talking about ?
Create a shortcut to the "Add/Remove Programs" control panel applet. Make sure you do this as an unprivileged user. Right-click and click on the "RunAs"... oh wait, it's not there. Hmm... Seems like you have to login with an Administrative account to "Add/Remove" programs from your system. That is an important, yet missing feature of the "RunAs" command. (I thought you knew Windows.)
You know why it is like that? I am taking an educated guess here, but having attempted to run installs after creating a shortcut and then using "RunAs" on the installer shortcut. I believe that "RunAs" only works for the initial application being called, it's not capable of spawning off sub-processes under the elevated privileges the application inherits from the initial "RunAs" activation.
Granted, there is a bit of security in doing so, at the same time, there's no reason that these sub-processes couldn't be ran in a sandbox under the control of the first process, similar to how UNIX handles parent and child processes. It could be written to make "RunAs" the primary process with ALL of the processes called by "RunAs" as subprocesses off of the parent. Thus, all processes spawned from child processes of the "RunAs" process are subservient to "RunAs". When "RunAs" is done with its job, all of the child processes would thus also be done as well.
See, with UNIX I can open up a shell, su to root and then open up an application. Unless I specifically choose to (with a flag), that application w
Your first statement shows how very little you actually know and understand about the architecture of Operating Systems.
Your second statement shows how very little you understand about how the Windows GUI functions and how it is possible to root a Windows machine, based upon the fundamental flaws in the methods that the Windows GUI uses to pass messages to other windows and backgruond processes on a given workstation. There was a proof of concept attack developed a little over a year ago, based upon years of research and regular complaints about the inherent, impossible to fix, problem with MS Windows internal messaging system. Look up the 'shatter' attack.
Your third statement shows how very little you understand about the UNIX and Linux security model and also the real difference in numbers between UNIX/Linux 'root' exploits and the numbers of Kernel Level exploits that are possible on Windows machines.
Your fourth statement is partially correct. Sure, Application vendors have continued to code applications that require more system access then may well be necesary, but that's also because many of those applications follow Microsoft's own development guidelines and attempt to use and reuse DLLs that exist on a given Windows installation.
Your last statement is close to what should be done. Microsoft should simply say, "F-it" and screw backwards compatibility for native Vista/XP/2003 applications. They should provide a free and automatic Virtual Machine environment to effectively sandbox all the older applications so that those applications have the "access" they require while still holding the security integrity of the machine in a high protection state.
Okay, now you are smoking something. Why don't you look up Multi-User and understand that Windows still isn't as Multi-User as UNIX is. Sure, the latest versions of Windows Server 2003 do allow multiple users to access a GUi simultaneously, but that development is still quite in it's infancy compared to the 30+ years of UNIX performing that quite admirably.
This is an application problem, not an OS problem.
An application program with components that ship with the operating system from the operating system vendor. So, I suppose that is sort of right, (If you want to be very obtuse about it) of course under UNIX you don't have those problems when using sudo or su into root and then running an application.
Yes, SYSTEM is about as close as you get on Windows to 'root' on unix. What's your point ?
The point is that if a malicious application elevates itself to "SYSTEM" level privileges, the only recourse is to wipe the machine completely. You are effectively 'rooted' and there is no method of truly protecting that level of the OS as an Administrator, since you are effectively cut out from it.
You have NFI what you're talking about.
Then enlighten me.
Bravo. I couldn't have said it better myself. (Mostly because I didn't have the time to look that proof of concept way of smashing through Windows security via an unprivileged user account.)
I have had unprivileged users hose systems. It can and does happen.
If it isn't integrated into the OS, please open up your "Program Files" directory, right-click on the "Internet Explorer" folder and delete it from your hard drive. You should have no problem in doing this and your computer should experience no problems.
The only problems you might experience would be the loss of a "default" web browser that you would need to reset. (If it isn't integrated into the OS.)
Please post your results.
Remember the big court case against Microsoft a handful of years back? Microsoft claimed time and time again that they couldn't remove Internet Explorer, because THEY HAD INTEGRATED IT INTO THE OS. How could that fact be considered an opinion when Microsoft entered it as FACT in the court case where they were found to be abusing their monopoly status?
The kicker is, that even as an Administrator on a Windows machine, you aren't at Ring 0, you are, at best, sitting in Ring 1.
If you were really Ring 0, then you could interupt, restart or kill programs running "SYSTEM" level privileges.
The UNIX sudo can also be set to allow only particular users to run it, instead of letting everyone on a given system use the sudo command.
It's not the command that is superior, so much as the underlying security model that allows a user to elevate their privileges temporarily to run any application, from installing to major setting changes. The Windows "RunAs" guffaws at installing applications(that require and admin account), using "Administrator" in the "RunAs" window, while logged in as an unprivileged user.
Do you mind explaining how it isn't?
IE exploits can change SYSTEM binaries and libraries. If it was a "User Space" application, instead of something else, it wouldn't be able to do that.
I have had users, that I specifically setup as unprivileged, find their way onto the Internet with IE and completely hose the system. Tell me how an unprivileged user, running a web browser, should be capable of diong that?
If IE wasn't integrated into the OS in some way beyond being a simple "User Space" application, then it wouldn't have been possible for them to do what they did. Also, if it wasn't integrated into the OS, I should be able to right-click and delete the IE directory without detrimental effect, beyond simply needing to address what the default web browser on the system is.
Since you are so sure it isn't integrated into the OS, why don't you open up your program files directory and simply delete IE off the PC and then go about your business. Please, post your results.
Bingo!
You just answered that yourself. You see "System Binaries" should never be alterable/replaceable by a "User Space" application. Web Browsers are supposed to be purely "User Space" applications, but IE isn't held to that standard, hence the ability t "root" a Windows machine directly through the Internet Explorer web browser.
My work here is done.
True, IE doesn't run in the kernel.
So, why is it that many IE Exploits result in Kernel Level takeovers of vulnerable machines?
The statement "security cannot be retro-fitted to a system" holds very true.
That's why UNIX is very comparmentalized and each component isn't tightly integrated with each and every other component on the system. This means when you are "retro-fitting" a subsystem of UNIX you aren't changing the ENTIRE OS, just that one piece, which is significantly easier then trying to patch a security hole in a massive pile of integrated code, like MS Windows is.
The evidence of the problems with the the Windows development model is showcased in that virtually every single flaw exploited has almost always resulted in a total compromise of the system, not just a compromise of one subsystem giving the attacker limited access to the total system.
As you are a Home User, I won't knock you for not understanding the true difference between what an effective User-Level and Multi-User OS is and what MS has provided.
While they have made major leaps forward, with the "RunAs" feature, there are still significant applications that cannot be run using the "RunAs" feature. It only goes so far.
Then, there is the SYSTEM group. This "Group" is controlled by the computer itself and if an application good or bad, runs under the SYSTEM level privileges, there is no method for even an administrator of the machine to kill or otherwise control what is going on, without rebooting/rebuilding the OS.
Effectively, you do not "control" or have "full control" as an available option on a Windows machine and at best, you have Ring 1 access and never Ring 0 access to the OS and its internals.