I have a question about how our privilege escalation policy interacts with the desktop_admin_r group.
Is a member user of desktop_admin_r considered an "unprivileged user"?
Tim. */
On Thu, 2010-05-27 at 09:49 -0400, Matthias Clasen wrote:
On Thu, 2010-05-27 at 12:01 +0100, Tim Waugh wrote:
I have a question about how our privilege escalation policy interacts with the desktop_admin_r group.
Is a member user of desktop_admin_r considered an "unprivileged user"?
No, he or she is considered privileged.
Right. Due to the discussions on the draft of this policy it contains this rather ugly paragraph providing specific definitions here:
"Authentication via provision of the root password always counts as administrative authentication. In the case of mechanisms such as sudo which allow authentication with a user's own password to grant root privileges, this form of authentication can be considered administrative authentication when so configured by the system administrator. In the case of an approved Fedora spin which automatically grants administrative privileges to the first created user account, authentication as that user can be considered administrative authentication; the same applies to any user account subsequently granted those privileges by the system administrator."
The relevant bit here is the last sentence, which was intended to cover the whole desktop_admin_r stuff. Let me know if it's factually off.
On Thu, 2010-05-27 at 08:23 -0700, Adam Williamson wrote:
The relevant bit here is the last sentence, which was intended to cover the whole desktop_admin_r stuff. Let me know if it's factually off.
Seeing as desktop_admin_r is actually part of the default spin, can we add some text which explicitly exempts users in that group from the privilege escalation policy?
In other words, can we say something along the lines of "it's fine for the default spin to ship policykit files allowing desktop_admin_r users to do stuff without passwords being required"?
Tim. */
On Thu, 2010-05-27 at 16:53 +0100, Tim Waugh wrote:
On Thu, 2010-05-27 at 08:23 -0700, Adam Williamson wrote:
The relevant bit here is the last sentence, which was intended to cover the whole desktop_admin_r stuff. Let me know if it's factually off.
Seeing as desktop_admin_r is actually part of the default spin, can we add some text which explicitly exempts users in that group from the privilege escalation policy?
In other words, can we say something along the lines of "it's fine for the default spin to ship policykit files allowing desktop_admin_r users to do stuff without passwords being required"?
That's exactly what the paragraph already says, except in a more general way so it isn't particular to any specific implementation.
"In the case of an approved Fedora spin which automatically grants administrative privileges to the first created user account, authentication as that user can be considered administrative authentication; the same applies to any user account subsequently granted those privileges by the system administrator."
This is meant to mean (:>) that it's fine for a spin to give the first created user admin privileges they can use without further authentication, and that it's fine for other accounts to be properly granted such privileges. Is there something desktop_admin_r is doing that's not captured there?
On Thu, 2010-05-27 at 09:02 -0700, Adam Williamson wrote:
authentication; the same applies to any user account subsequently granted those privileges by the system administrator."
Ah, OK, and this includes being added to *any* non-default groups I guess?
Thanks for clarifying.
Tim. */
On Fri, 2010-05-28 at 10:40 +0100, Tim Waugh wrote:
On Thu, 2010-05-27 at 09:02 -0700, Adam Williamson wrote:
authentication; the same applies to any user account subsequently granted those privileges by the system administrator."
Ah, OK, and this includes being added to *any* non-default groups I guess?
Thanks for clarifying.
Yeah. I'll try and reword the policy a bit, since it obviously isn't clear, or else we wouldn't have had to have this conversation :)
devel@lists.stg.fedoraproject.org