Talk:Comparison of privilege authorization features

Hi. While this is a good start, in the current incarnation, it is no more useful than having a bunch of links to the different articles. While reading a comparison, one would expect a contrast between the general class of actions they kick in, technologically savvy users might want detailed info on this front like (from UAC PoV) sending which WM_ messages require elevations, which other actions at the process level mandate so etc. Also need to mention other ways to gain elevated privileges. In windows, the ctrl+alt+enter when from the start menu search bar etc etc. It will be an intriguing journey ahead. :) --soum^সৌমোyasch 06:19, 13 March 2007 (UTC)

Thanks for getting this started... I'll fill out bits and pieces of information in the coming days. In the longer term, we will probably want to divvy things up by "approach" rather than by specific implementations. It's a lot easier to do a compare/contrast of specific implementations when discussing an approach.

We should probably mention Security-Enhanced Linux somewhere as well. -/- Warren 07:12, 13 March 2007 (UTC)

Why I removed some information

Warrens partially reverted my last edit to this article (diff), saying it was not justified. Please allow me to explain my reasoning behind this change:

1. I added information on the security shield to the User Account Control article. Placing security shields next to tasks likely to trigger a UAC prompt is a feature of the Vista UI, and is unrelated to how UAC works. The security shields always appear whether UAC is on or off.
2. [removed, see note below]

—Remember the dot ^(talk) 03:00, 16 March 2007 (UTC)

Never mind about point 2. The secure attention key article has useful information relevant to the discussion. —Remember the dot ^(talk) 03:04, 16 March 2007 (UTC)

Simplicity of dialog

"By default in UAC, an administrator simply confirms or denies an action, instead of re-entering their password each time. While this approach is simpler, it is also less secure.[9] If the user physically walked away from the computer, another person could walk up and have administrator privileges over the system. Also, if the security of the Secure Desktop was compromised in some way, or the Secure Desktop was disabled, malicious applications would easily be able to gain administrator privileges by spoofing a mouse click on the "Allow" button, or by using keystroke logging to record the administrator's password."

That last part of the last sentence doesn't seem to make sense in the context: the rest of the paragraph is criticising the the way you don't have to type in your password if you're logged in as a member of the admin group, but the last part is a about recording the password?

Not to mention the whole second sentence is a complete tautology; it's basically saying "if someone comes up with a way to compromise the system, your system could be compromised". Well, obviously; and also by definition something that applies to all the systems being compared, rather than just UAC; yet it's couched as a criticism of UAC. Any objections to just deleting the whole second sentence?

Simxp 00:42, 4 May 2007 (UTC)

I think it should be left the way it is. The second sentence explains that the price of simplicity is reduced security. The last sentence is trying to explain why it is a really bad idea to turn off the Secure Desktop. If you turn it off, UAC can be trivially bypassed. Even if UAC asks you for your password, without the secure desktop a malicious application could intercept and record the password as you type it in. —Remember the dot ^(talk) 00:53, 4 May 2007 (UTC)

I accept your point about making it clear that it's a bad idea to turn off secure desktop (/ input locking with gksudo), so I've left it in there, but the entire second part of that paragraph (the bit about secure desktop) is in the wrong section anyway -- it was in "Simplicity of Dialogue", so I've moved it to the correct section in "Security Considerations", and made it slightly more general. -- simxp (talk) 18:04, 12 July 2007 (UTC)

---

I think that pfexec/rbac needs to be mentioned in this article. http://developers.sun.com/developer/technicalArticles/opensolaris/pfexec.html —Preceding unsigned comment added by 72.227.129.108 (talk) 19:30, 13 December 2008 (UTC)

"Capture"?

Does anyone know the meaning in the use of the word "capture" where the article states "In GNOME, PolicyKit directs the X server to capture all keyboard and mouse input. Other desktop environments using PolicyKit may use their own mechanisms."? Is this a form of blocking of outside copying? This may need clarification. - KitchM (talk) 06:23, 20 November 2010 (UTC)

Privilege elevation redirect

"Privilege elevation" redirects to this page. Any reason this does not redirect to Privilege escalation? and should this article be merged with that? ozhu (talk · contribs) 18:26, 17 September 2019 (UTC)

Обойти двухшаговую проверку

Востоновить акаунт (89832154326) 89.113.137.51 (talk) 23:39, 20 November 2021 (UTC)

+855973207295

Suxusod Usudkf Dh Idhfng So xtuwm 36.37.193.151 (talk) 20:32, 3 October 2024 (UTC)