Hello,
There is a major flaw with this entire approach (in any OS). The issue is
that a lot of malware, trojans, etc. tend to install themselves via
exploits. Exploits by their inherent definition usually defeat the security
mechanisms in place.
No security system is invulnerable to exploits.
You are of course correct about exploits, but I'm not sure I
understand how this affects UAC, and I am very confused as to how you
see UAC as a major flaw.
Pretending for a second that one had a mythical system that could not
be exploited, if there was no UAC-equivalent, and one were logged in
as an admin, what difference would the unexploitability make when
running programs?
UAC assures that even if you are logged in as an admin, a non-admin
tool will not be able to perform admin tasks (unless it performs an
exploit). Isn't that just as important as guarding against exploits?
Why is keeping code that does not require privilege from running with
privilege a bad thing?
That is why I prefer Linux's approach to the problem rather than UAC. UAC
will still let the program do whatever it wants if the user clicks Yes.
Linux on the other hand (save for exploits) the program has *no chance*
whatsoever unless I personally started it with elevated permissions.
They key difference being between acting and reacting.
It's impossible under Linux to accidentally start an app with elevated
permissions! It just simply takes too much "work". It's a decision I have
to make ahead of time.
UAC all it takes is a wrong accidental mouse click on a prompt as all I am
doing is reacting to its prompt.
You seem to imply that in Windows, UAC is just popping up at random
times and is not tied to any event in particular.
This is not true - UAC is exactly like sudo... unless a program is
attempting to exploit sudo/UAC, the prompt (enter password in sudo or
continue/cancel in uac) only appears in response to a user taking
administrative action.
I understand your point here to be that it takes more work to start an
admin program in Linux, and so that makes it more secure.
UAC and SUDO allow users (accidentally or not) to elevate
applications, but prevent *applications* from doing this of their own
accord.
They BOTH do this using the same check-with-the-user model, and they
are BOTH reactionary and subject to user error.
In Windows -> In Linux
1. Double-click admin app -> Run admin app w/ sudo
2. UAC prompt -> sudo prompt
3. Admin App is executed if user confirms
You are arguing on point #1, saying that the user is showing "more
intent" to run the admin application by using sudo ...
But it seems to me the user shows just as much intent by
double-clicking the application in windows, especially since admin
actions are adorned with the UAC shield icon. UAC prompts from actions
that don't have the UAC icon will be suspicious, just as running an
application w/out sudo that prompts for the root password is
suspicious in linux.
Regardless, intent is determined by the security model on #2, not #1
.... this is how the sytem verifies that the user is in fact the one
who is performing the admin action.
Any extra steps in #1 just serves to delay the user from executing the
admin app, it doesn't do anything to prevent privilege elevation by
other applications.
An out-of-the-blue UAC prompt would look just as suspicious in Windows
as would an out-of-the-blue sudo prompt on a Linux box.
They are the same model, just implemented differently
