That is my main problem with cities in general. You can eliminate pollution, make the city bike- and walk-friendly, reduce crime etc., but living together with tens of thousands of people tends to increase psychological stress. Well at least it increases my level of stress living in a city, but I guess I'm not alone.
No, you are not alone. Around 300 millions of people agree with you. Almost everyone outside US disagrees, and laughs at how Americans yearn for bucolic rural lifestyle, how they fear and hate each other, and how they end up in suburbs that can be best described as giant cemeteries for the living.
Setting aside the fact that keylogging in X can be done without root, yours is another example of how gksudo is inferior in terms of security to UAC.
Try it. gksudo switches into a "locked" mode before asking for the password, so keyboard events are not passed to other applications.
A process without admin rights in Windows cannot imitate a UAC prompt.
It can run another process that will do it on its behalf. sudo can limit the set of command line options that can be run through it, so such things can (and should, though usually aren't) be prevented, UAC with its lack of policy, does not do it at all, and relies on the user divining the validity of the actions that it doesn't even reliably attribute to the program.
Only if said malware is already running with your permissions -- what is a separate thing that should be prevented by sandboxing, and I agree that it should be used more widely than it is now.
On my system at work, I have a couple gigs of software I have installed to ~ because I don't have root.
If you don't have root, everything that was said about sudo is irrelevant -- if you run anything malicious, at very least it will be confined to your account. If your sysadmin keeps, say, incremental backups of your home directory at the same host, you will even be able to recover from this.
(Just FYI, except for installers, there's barely more reason to run an executable on Windows than there is on Linux.
On a properly configured system with software written in a sane manner, there are no reasons to run random untrusted stuff. Unfortunately Windows and only Windows is "blessed" with things like data being distributed in executable self-extracting archives, lack of repositories of software with consistent tracking of dependencies, poor support for common file formats, etc., so people end up distributing everything in an executable.
And if you don't trust the installer, why do you trust the package from the package manager?)
Because even if I trust the software developer, I also trust a package maintainer, distribution repository maintainer, authors of apt, certificate authority and people who developed signature checking procedure a whole lot more than I trust each and every person that did, or could, add something to an executable installer on the way between a host where a piece of software was compiled and my computer. People seem to forget that not too long ago the only way malware could propagate itself was by attaching to perfectly legitimate executables so it remained completely invisible to the victims until it was too late -- and it was a massive pain in the ass even then.
I don't know if you noticed, but this is the same on Linux, at least with compiled executables. (I did notice that for scripts it asks if you want to open or run.)
But only for files with executable permission. That is never set unless either:
1. It's installed with a package manager. 2. User explicitly set it. 3. It's extracted from an archive specifically as a directory with files.
You can't download a file, and it will automagically become executable, no matter what is in it. And GUI will at very least steer you away from doing it with archives and packages.
And I still think you're deluding yourself if you think that adding "just double click on the file and choose extract" in the email wouldn't catch a sizable population of people if the world was instantly moved from Windows to Linux (if people were as proficient with Linux after the switch as they are with Windows now).
Except it won't. You can't email a file that will run on a double-click -- unless your mail reader supports.desktop, the only file that allows things to execute without itself being executable.
Oh, I think I may understand your beef with the.desktop files now: you can actually launch what's in the exec line by double clicking on it. Is that your problem?
If so, I somewhat see where you're coming from. I was only thinking of them as files that were read when Gnome logged on, so double clicking on them didn't enter the picture.
This is exactly the problem. No other kind of file, no matter what is in it, will run anything unless it has executable permission, so user can click on things until his mouse will wear out, and all he will see is viewers. He has to choose to extract the file, and archive manager will even, very unhelpfully, not even automatically change into directory that he created, so he has to specifically choose to uncompress things. If he will use any archive-mounting option or file manager that shows archives as directories, he will get a non-executable file.
Except now there is one exception to this rule --.desktop, the only broken link in the chain of distrust.
Yeah, that users won't run crap is well justified.
It only happens because on Windows "Run" and "Open" are the same action in GUI, and almost everything is distributed as an executable. Even things that have no actual executable content are often in self-extracting archives. Linux does not default to this download-and-execute sequence if user just blindly click on links and icons -- any modern GUI will steer such user into a viewer and won't create an executable file unless user selects "Extract" option, then selects or makes a target directory.
The.desktop files contain rather more information than just what program to run. How would you deal with that? Specially-formatted comments in the script? Pass the script a command line argument?
No, I would just make a special "interpreter" that takes existing.desktop format plus #! line and runs whatever is in "Exec" entry. The only reason for it would be consistency -- nothing would be lost if executable.desktop files always started with "#!/bin/false" because the true purpose of the executable bit is to tell file/desktop manager/menu program that.desktop file is indeed allowed to execute things, the interpreter will exist just for consistency sake, so I can say
./Desktop/Firefox.desktop &
and it will do the same as
./Desktop/Firefox.sh &
as opposed to a bunch of errors from shell that would happen if.desktop files in the current #!-less format were made executable.
...contributed to the development of efficient cars while Nazi polluted the environment over the course of WWII.
No, seriously, who fucking cares what Gates or Microsoft say about CO2? Or Uranium. Or puppies. There is not enough fuel on this planet to create the amount of damage they caused to science, engineering and culture over their more than three decades of their reign over everything even remotely related to computing.
(Godwin can kiss my ass -- Microsoft and Nazi are by now at the comparable scale as far as lasting consequences are concerned).
You call these "Windows problems". Most people call them, "how computers work".
Running executable not installed by a package manager or a sysadmin, and not written by the user himself is something that no user should ever do on a non-Windows system.
execute bits offer zero security in the context of a desktop usage and are nothing but an annoyance.
It's only an annoyance if the user has to run random shit he downloaded from untrusted locations -- what means that his computer is already pwned. Anything that a user can do to validate the file he is about to run has to be more of an "annoyance" than setting up an executable bit after he verified that executable is indeed trusted, so if the user is "annoyed" by having to set this bit and not annoyed by having to verify thing he is chmod'ing, he is doing something terribly wrong, and no security model is going to help him.
The behavior of all newly created files non being able to be executed can be replicated in Windows quite easily using default ACLs,
Except, of course, Windows file manager and large amount of Windows software do not provide usable support for it. There is also a matter of what "executable" means in Windows vs. what "executable" means in a Unix-like system.
but it is only used in situations where it has a practical use, like servers that allow users to upload files.
Servers are not supposed to be capable of executing anything other than a predefined set of scripts in the first place (or anything at all). This is a completely different matter.
Sandboxing of processes (SELinux, AA, PolicyKit and yes, UAC) is the future of security - not execute bits and file formats.
Sandboxing should never involve asking user about anything -- a process born in a sandbox dies in a sandbox, and should never access anything outside the sandbox other than through a minimal sanitized interfaces (say, GUI). The only time a user may be asked would be when a file produced by a sandboxed process should be made available to other processes -- however at that point nothing should be actually executed.
Neither PolicyKit nor UAC are sandboxes -- they take a regular process and determine its access to services the process would otherwise not be able to access. They may be used from a sandbox, however this is not their primary purpose. And, of course, PolicyKit has, well, policy at its core while UAC is a computer equivalent of the current airport screening procedures -- plenty of noise and delays, and no real improvement.
Except there will be no one to perform this step -- without a.desktop file there is no way to run an arbitrary executable as the user unless you are already an executable running as that user. Buffer overflow or a similar exploit would be the only way to do so.
In your example you have created an executable python file by yourself, however you provided no explanation how such a file would appear on the user's filesystem. It would be reasonable to assume that.desktop file would be able to just run python with it as an argument, and that requires current (insecure) handling of.desktop files.
Hell, all the malware writer would need to do is put things into a.tar.gz file and say "extract and run".
All GUI archive managers require a separate "Extract" command (that preserves execute permission), that is different from the default action that is to view a file (without giving it an execute permission even if it is present in the archive). I guess, it will be better if "extract" was not just separate but produced some kind of warning and confirmation screen by default in a "newbie" mode, however for a GUI-only user there is already a pretty noticeable distinction. For anyone but total newbies it should be obvious that the user should NEVER run anything he downloads unless he is installing some software that is not in a repository -- as root, as his own user or as anyone else.
Handling of.desktop files in file managers is, indeed, a problem that must be fixed. Personally I would just turn them into traditional #! scripts with "interpreter" doing what a file manager would, and file manager refusing to execute anything in them unless they are executable.
The fact that.desktop files can contain full command lines AND don't have to have any non-default permissions themselves, is stupid and should be changed. It's a broken link in otherwise reliable mechanism that prevents anything without executable bit from being executed by merely clicking on something.
It assumes that there is a constantly-running hostile process, what means, pretty much everything that desktop environment does may be altered at that point. Assuming that user did not run chmod +x on everything he downloads, this would require a completely separate exploit to happen before the user does anything privileged.
I agree that this model is not as secure as it should be, however it's be pretty trivial to eliminate gksudo prompts completely and let applications that should have administrative permissions run with them automatically, thus neither causing any inconvenience to the user nor keeping anything cached. There is no legitimate reason to run, say, Synaptic, without root privileges, so not asking the user won't make system any less secure, as long as only user can run the executable. For example, a setuid wrapper that clears potentially exploitable environment and command line, should be sufficient even for the most bloated monstrosities that are trusted enough to be used for administration. Splitting things up and using PolicyKit to run the backend while GUI remains unprivileged, will be even better. Using capabilities for applications that need elevated but limited privileges helps, too.
Windows UAC doesn't help with that, and provides no way to implement a better solution.
The length of time the password is cached is irrelevant. One second is sufficient because a rogue process can quite easily sit in the background monitoring every process a user invokes.
It's not trivial for a hostile application to get executed on a Linux box in the first place (and it would mean that user's account is compromised already).
killing off a terminal window may be required, but a dumb user would just think xterm crashed and think nothing more of it.
This is why it's important to make sure that terminal programs never crash -- if you see it happened, something is definitely wrong. And, of course, nothing can make a system secure if dumb person has administrative access to it.
There is no luck involved. The only way to prevent this is to disable password caching completely.
This is a separate issue, and security-conscious users do just that. Thankfully there are very few situations when users end up running anything as root.
From a standpoint of privilege escalation, UAC is pretty much functionally equivalent to gksudo. It allows processes to run with elevated rights. The mechanisms are different, and one is 100x more secure than the other, but the end result is the same.
Unfortunately UAC mostly creates an impression that user is in control of something, as user still has no way to know if the application he is running is supposed to run with elevated privileges, or not. In the end, it's all a matter of trusting executables the user has installed, and at this point the usual Windows problems apply -- all files may be executed if they are in executable format, archives and installers are usually packaged as executables, sandboxing is nearly nonexistent, etc.
The alternative to UAC was to have legacy applications that don't run properly with limited rights fail, en masse. While breaking bad apps is the technically correct and ideal solution, it is not acceptable given the consumer demand for backwards compatibility. The typical computer user is not technically adept enough to decide beforehand that they need to launch an application with elevated privileges, so some sort of mechanism like UAC is necessary to hold their hand.
That's because Microsoft imitated sudo and not PolicyKit, that places the choice into the hands of the system developer or a sysadmin, not user.
The difference is, this is the race against the user, not another process. Smart user will invalidate timestamps before doing anything that involves a non-administrative applications anyway, and this is one thing that should be added to the default GUI configuration, so less smart users will be encouraged to do so.
As it should not be. It would be idiotic for Microsoft to configure UAC to have that option because it would essentially introduce a permanent privilege escalation vulnerability. There's convenient and there's downright, stupid. Cached credentials done the way linux/BSD and SUDO does it, would be a security disaster on a mainstream desktop platform.
sudo uses time limit for credentials -- this may not be the best way to achieve high security, however in most of real-life use it's sufficient to prevent privilege escalation for all but the luckiest trojan horses that happen to activate right after the user started the installation of something. In a desktop system it's a pretty good solution compared to all other methods. People who are concerned about time limits can make a large button that runs sudo -k and put it on the panel.
Windows UAC solves the wrong problem -- it ask the user for something that he is not supposed to make a choice about. There are no things that user is supposed to "decide" if they should or should not be allowed to run as root/admin -- there are things that should always run as admin, and things that shouldn't. Nothing in the world, least of all the user, is supposed to ever move them from one category to the other. The role of the password prompt in sudo/gksudo is to let the user confirm that it's he who requested the supposedly privileged application to run. If something doesn't need this confirmation, it has setuid bit set on the executable, so sudo mechanism won't be necessary, or implemented as a constantly running daemon. The problem is, most administrative applications with user interface are not simple enough to be trusted with setuid bit -- it's possible that they can be coerced into performing some actions that can be a part of a privilege escalation exploit. Asking the user breaks those exploits because user will see a prompt when he did not start an administrative application.
PolicyKit/ConsoleKit allow more fine-grained security models, however they do it by handling, as the name suggests, a policy, not by giving the user a "choice" between running a virus and rendering system unbootable by crashing an upgrade process.
...and this is why US has aristocracy that it just as retarded as 17th century Europe. Good going, guys.
Some people go to school to study. They become productive members of society, and they are the reason anything at all is still being done. In US they are a very small group, they have absolutely nothing in common with the mix of dumb rednecks, greedy assholes and the above mentioned silver-spoon aristocrats that is known as American society -- and they do absolutely everything of any value.
Slashdot Mirror
That is my main problem with cities in general. You can eliminate pollution, make the city bike- and walk-friendly, reduce crime etc., but living together with tens of thousands of people tends to increase psychological stress. Well at least it increases my level of stress living in a city, but I guess I'm not alone.
No, you are not alone. Around 300 millions of people agree with you. Almost everyone outside US disagrees, and laughs at how Americans yearn for bucolic rural lifestyle, how they fear and hate each other, and how they end up in suburbs that can be best described as giant cemeteries for the living.
This is more what I see here on slashdot. Somewhere in the middle is the common ground.
That's because facts do not exist, and all opinions are equally right, amirite?
That never stopped American politicians before.
Turtles.
Or rickroll is slashdotted?
Sometimes you have to implement Ethernet MAC in VHDL (or, more likely, fix the implementation Xilinx gave you)...
Really? Mine is fe:dm:ed:ed:ba:be :D
"dm" is not a hex number.
Setting aside the fact that keylogging in X can be done without root, yours is another example of how gksudo is inferior in terms of security to UAC.
Try it. gksudo switches into a "locked" mode before asking for the password, so keyboard events are not passed to other applications.
A process without admin rights in Windows cannot imitate a UAC prompt.
It can run another process that will do it on its behalf. sudo can limit the set of command line options that can be run through it, so such things can (and should, though usually aren't) be prevented, UAC with its lack of policy, does not do it at all, and relies on the user divining the validity of the actions that it doesn't even reliably attribute to the program.
Only if said malware is already running with your permissions -- what is a separate thing that should be prevented by sandboxing, and I agree that it should be used more widely than it is now.
But my MAC address IS fe:ed:fa:ce:be:ef , you insensitive clod!
(I am an FPGA developer).
I guess, with flying penises that don't look like they are from a video game made in 90's.
Down with particle floods! If you want to attack people with flying penises, have decency to make those flying penises out of prims.
On my system at work, I have a couple gigs of software I have installed to ~ because I don't have root.
If you don't have root, everything that was said about sudo is irrelevant -- if you run anything malicious, at very least it will be confined to your account. If your sysadmin keeps, say, incremental backups of your home directory at the same host, you will even be able to recover from this.
(Just FYI, except for installers, there's barely more reason to run an executable on Windows than there is on Linux.
On a properly configured system with software written in a sane manner, there are no reasons to run random untrusted stuff. Unfortunately Windows and only Windows is "blessed" with things like data being distributed in executable self-extracting archives, lack of repositories of software with consistent tracking of dependencies, poor support for common file formats, etc., so people end up distributing everything in an executable.
And if you don't trust the installer, why do you trust the package from the package manager?)
Because even if I trust the software developer, I also trust a package maintainer, distribution repository maintainer, authors of apt, certificate authority and people who developed signature checking procedure a whole lot more than I trust each and every person that did, or could, add something to an executable installer on the way between a host where a piece of software was compiled and my computer. People seem to forget that not too long ago the only way malware could propagate itself was by attaching to perfectly legitimate executables so it remained completely invisible to the victims until it was too late -- and it was a massive pain in the ass even then.
I don't know if you noticed, but this is the same on Linux, at least with compiled executables. (I did notice that for scripts it asks if you want to open or run.)
But only for files with executable permission. That is never set unless either:
1. It's installed with a package manager.
2. User explicitly set it.
3. It's extracted from an archive specifically as a directory with files.
You can't download a file, and it will automagically become executable, no matter what is in it. And GUI will at very least steer you away from doing it with archives and packages.
And I still think you're deluding yourself if you think that adding "just double click on the file and choose extract" in the email wouldn't catch a sizable population of people if the world was instantly moved from Windows to Linux (if people were as proficient with Linux after the switch as they are with Windows now).
Except it won't. You can't email a file that will run on a double-click -- unless your mail reader supports .desktop, the only file that allows things to execute without itself being executable.
Oh, I think I may understand your beef with the .desktop files now: you can actually launch what's in the exec line by double clicking on it. Is that your problem?
If so, I somewhat see where you're coming from. I was only thinking of them as files that were read when Gnome logged on, so double clicking on them didn't enter the picture.
This is exactly the problem. No other kind of file, no matter what is in it, will run anything unless it has executable permission, so user can click on things until his mouse will wear out, and all he will see is viewers. He has to choose to extract the file, and archive manager will even, very unhelpfully, not even automatically change into directory that he created, so he has to specifically choose to uncompress things. If he will use any archive-mounting option or file manager that shows archives as directories, he will get a non-executable file.
Except now there is one exception to this rule -- .desktop, the only broken link in the chain of distrust.
Yeah, that users won't run crap is well justified.
It only happens because on Windows "Run" and "Open" are the same action in GUI, and almost everything is distributed as an executable. Even things that have no actual executable content are often in self-extracting archives. Linux does not default to this download-and-execute sequence if user just blindly click on links and icons -- any modern GUI will steer such user into a viewer and won't create an executable file unless user selects "Extract" option, then selects or makes a target directory.
The .desktop files contain rather more information than just what program to run. How would you deal with that? Specially-formatted comments in the script? Pass the script a command line argument?
No, I would just make a special "interpreter" that takes existing .desktop format plus #! line and runs whatever is in "Exec" entry. The only reason for it would be consistency -- nothing would be lost if executable .desktop files always started with "#!/bin/false" because the true purpose of the executable bit is to tell file/desktop manager/menu program that .desktop file is indeed allowed to execute things, the interpreter will exist just for consistency sake, so I can say
and it will do the same as
as opposed to a bunch of errors from shell that would happen if .desktop files in the current #!-less format were made executable.
...contributed to the development of efficient cars while Nazi polluted the environment over the course of WWII.
No, seriously, who fucking cares what Gates or Microsoft say about CO2? Or Uranium. Or puppies. There is not enough fuel on this planet to create the amount of damage they caused to science, engineering and culture over their more than three decades of their reign over everything even remotely related to computing.
(Godwin can kiss my ass -- Microsoft and Nazi are by now at the comparable scale as far as lasting consequences are concerned).
You call these "Windows problems". Most people call them, "how computers work".
Running executable not installed by a package manager or a sysadmin, and not written by the user himself is something that no user should ever do on a non-Windows system.
execute bits offer zero security in the context of a desktop usage and are nothing but an annoyance.
It's only an annoyance if the user has to run random shit he downloaded from untrusted locations -- what means that his computer is already pwned. Anything that a user can do to validate the file he is about to run has to be more of an "annoyance" than setting up an executable bit after he verified that executable is indeed trusted, so if the user is "annoyed" by having to set this bit and not annoyed by having to verify thing he is chmod'ing, he is doing something terribly wrong, and no security model is going to help him.
The behavior of all newly created files non being able to be executed can be replicated in Windows quite easily using default ACLs,
Except, of course, Windows file manager and large amount of Windows software do not provide usable support for it. There is also a matter of what "executable" means in Windows vs. what "executable" means in a Unix-like system.
but it is only used in situations where it has a practical use, like servers that allow users to upload files.
Servers are not supposed to be capable of executing anything other than a predefined set of scripts in the first place (or anything at all). This is a completely different matter.
Sandboxing of processes (SELinux, AA, PolicyKit and yes, UAC) is the future of security - not execute bits and file formats.
Sandboxing should never involve asking user about anything -- a process born in a sandbox dies in a sandbox, and should never access anything outside the sandbox other than through a minimal sanitized interfaces (say, GUI). The only time a user may be asked would be when a file produced by a sandboxed process should be made available to other processes -- however at that point nothing should be actually executed.
Neither PolicyKit nor UAC are sandboxes -- they take a regular process and determine its access to services the process would otherwise not be able to access. They may be used from a sandbox, however this is not their primary purpose. And, of course, PolicyKit has, well, policy at its core while UAC is a computer equivalent of the current airport screening procedures -- plenty of noise and delays, and no real improvement.
Except there will be no one to perform this step -- without a .desktop file there is no way to run an arbitrary executable as the user unless you are already an executable running as that user. Buffer overflow or a similar exploit would be the only way to do so.
In your example you have created an executable python file by yourself, however you provided no explanation how such a file would appear on the user's filesystem. It would be reasonable to assume that .desktop file would be able to just run python with it as an argument, and that requires current (insecure) handling of .desktop files.
Hell, all the malware writer would need to do is put things into a .tar.gz file and say "extract and run".
All GUI archive managers require a separate "Extract" command (that preserves execute permission), that is different from the default action that is to view a file (without giving it an execute permission even if it is present in the archive). I guess, it will be better if "extract" was not just separate but produced some kind of warning and confirmation screen by default in a "newbie" mode, however for a GUI-only user there is already a pretty noticeable distinction. For anyone but total newbies it should be obvious that the user should NEVER run anything he downloads unless he is installing some software that is not in a repository -- as root, as his own user or as anyone else.
Handling of .desktop files in file managers is, indeed, a problem that must be fixed. Personally I would just turn them into traditional #! scripts with "interpreter" doing what a file manager would, and file manager refusing to execute anything in them unless they are executable.
The fact that .desktop files can contain full command lines AND don't have to have any non-default permissions themselves, is stupid and should be changed. It's a broken link in otherwise reliable mechanism that prevents anything without executable bit from being executed by merely clicking on something.
It assumes that there is a constantly-running hostile process, what means, pretty much everything that desktop environment does may be altered at that point. Assuming that user did not run chmod +x on everything he downloads, this would require a completely separate exploit to happen before the user does anything privileged.
I agree that this model is not as secure as it should be, however it's be pretty trivial to eliminate gksudo prompts completely and let applications that should have administrative permissions run with them automatically, thus neither causing any inconvenience to the user nor keeping anything cached. There is no legitimate reason to run, say, Synaptic, without root privileges, so not asking the user won't make system any less secure, as long as only user can run the executable. For example, a setuid wrapper that clears potentially exploitable environment and command line, should be sufficient even for the most bloated monstrosities that are trusted enough to be used for administration. Splitting things up and using PolicyKit to run the backend while GUI remains unprivileged, will be even better. Using capabilities for applications that need elevated but limited privileges helps, too.
Windows UAC doesn't help with that, and provides no way to implement a better solution.
The length of time the password is cached is irrelevant. One second is sufficient because a rogue process can quite easily sit in the background monitoring every process a user invokes.
It's not trivial for a hostile application to get executed on a Linux box in the first place (and it would mean that user's account is compromised already).
killing off a terminal window may be required, but a dumb user would just think xterm crashed and think nothing more of it.
This is why it's important to make sure that terminal programs never crash -- if you see it happened, something is definitely wrong. And, of course, nothing can make a system secure if dumb person has administrative access to it.
There is no luck involved. The only way to prevent this is to disable password caching completely.
This is a separate issue, and security-conscious users do just that. Thankfully there are very few situations when users end up running anything as root.
From a standpoint of privilege escalation, UAC is pretty much functionally equivalent to gksudo. It allows processes to run with elevated rights. The mechanisms are different, and one is 100x more secure than the other, but the end result is the same.
Unfortunately UAC mostly creates an impression that user is in control of something, as user still has no way to know if the application he is running is supposed to run with elevated privileges, or not. In the end, it's all a matter of trusting executables the user has installed, and at this point the usual Windows problems apply -- all files may be executed if they are in executable format, archives and installers are usually packaged as executables, sandboxing is nearly nonexistent, etc.
The alternative to UAC was to have legacy applications that don't run properly with limited rights fail, en masse. While breaking bad apps is the technically correct and ideal solution, it is not acceptable given the consumer demand for backwards compatibility. The typical computer user is not technically adept enough to decide beforehand that they need to launch an application with elevated privileges, so some sort of mechanism like UAC is necessary to hold their hand.
That's because Microsoft imitated sudo and not PolicyKit, that places the choice into the hands of the system developer or a sysadmin, not user.
The difference is, this is the race against the user, not another process. Smart user will invalidate timestamps before doing anything that involves a non-administrative applications anyway, and this is one thing that should be added to the default GUI configuration, so less smart users will be encouraged to do so.
As it should not be. It would be idiotic for Microsoft to configure UAC to have that option because it would essentially introduce a permanent privilege escalation vulnerability. There's convenient and there's downright, stupid. Cached credentials done the way linux/BSD and SUDO does it, would be a security disaster on a mainstream desktop platform.
sudo uses time limit for credentials -- this may not be the best way to achieve high security, however in most of real-life use it's sufficient to prevent privilege escalation for all but the luckiest trojan horses that happen to activate right after the user started the installation of something. In a desktop system it's a pretty good solution compared to all other methods. People who are concerned about time limits can make a large button that runs sudo -k and put it on the panel.
Windows UAC solves the wrong problem -- it ask the user for something that he is not supposed to make a choice about. There are no things that user is supposed to "decide" if they should or should not be allowed to run as root/admin -- there are things that should always run as admin, and things that shouldn't. Nothing in the world, least of all the user, is supposed to ever move them from one category to the other. The role of the password prompt in sudo/gksudo is to let the user confirm that it's he who requested the supposedly privileged application to run. If something doesn't need this confirmation, it has setuid bit set on the executable, so sudo mechanism won't be necessary, or implemented as a constantly running daemon. The problem is, most administrative applications with user interface are not simple enough to be trusted with setuid bit -- it's possible that they can be coerced into performing some actions that can be a part of a privilege escalation exploit. Asking the user breaks those exploits because user will see a prompt when he did not start an administrative application.
PolicyKit/ConsoleKit allow more fine-grained security models, however they do it by handling, as the name suggests, a policy, not by giving the user a "choice" between running a virus and rendering system unbootable by crashing an upgrade process.
...and this is why US has aristocracy that it just as retarded as 17th century Europe. Good going, guys.
Some people go to school to study. They become productive members of society, and they are the reason anything at all is still being done. In US they are a very small group, they have absolutely nothing in common with the mix of dumb rednecks, greedy assholes and the above mentioned silver-spoon aristocrats that is known as American society -- and they do absolutely everything of any value.
No, but pretending that "chosen few" are not really in power is something relatively recent (18 century recent, to be exact).