Hi, all. So the privilege escalation policy went to FESco, who suggested some minor tweaks and a final run-by the mailing lists before it gets approved.
I have now adjusted the draft - https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalati... - to reflect all feedback from this list and from FESco. It will be reviewed again by FESco next week. Please raise any potential issues or further suggestions for adjustments before then. Of course, even if the policy is accepted by FESCo it will not be set in stone and changes and exceptions can be added in future as appropriate, but I'd like to have it as good as possible at first :) thanks all!
On 10-02-10 15:48:39, Adam Williamson wrote:
Hi, all. So the privilege escalation policy went to FESco, who suggested some minor tweaks and a final run-by the mailing lists before it gets approved.
I have now adjusted the draft - https://fedoraproject.org/wiki/User:Adamwill/ Draft_Fedora_privilege_escalation_policy
- to reflect all feedback from this list and from FESco. It will be
reviewed again by FESco next week. Please raise any potential issues or further suggestions for adjustments before then. Of course, even if the policy is accepted by FESCo it will not be set in stone and changes and exceptions can be added in future as appropriate, but I'd like to have it as good as possible at first :) thanks all!
"Directly read or write directly to or from system memory" has an extra (or out of order) "directly".
On Wed, 2010-02-10 at 17:19 -0500, Tony Nelson wrote:
"Directly read or write directly to or from system memory" has an extra (or out of order) "directly".
sigh. thanks.
On Wed, Feb 10, 2010 at 11:19 PM, Tony Nelson tonynelson@georgeanelson.com wrote:
On 10-02-10 15:48:39, Adam Williamson wrote:
Hi, all. So the privilege escalation policy went to FESco, who suggested some minor tweaks and a final run-by the mailing lists before it gets approved.
I have now adjusted the draft - https://fedoraproject.org/wiki/User:Adamwill/ Draft_Fedora_privilege_escalation_policy
- to reflect all feedback from this list and from FESco. It will be
reviewed again by FESco next week. Please raise any potential issues or further suggestions for adjustments before then. Of course, even if the policy is accepted by FESCo it will not be set in stone and changes and exceptions can be added in future as appropriate, but I'd like to have it as good as possible at first :) thanks all!
"Directly read or write directly to or from system memory" has an extra (or out of order) "directly".
How exactly is "system memory" defined? The term seems rather vague to me ...
On Wed, Feb 10, 2010 at 05:19:59PM -0500, Tony Nelson wrote:
On 10-02-10 15:48:39, Adam Williamson wrote:
Hi, all. So the privilege escalation policy went to FESco, who suggested some minor tweaks and a final run-by the mailing lists before it gets approved.
I have now adjusted the draft - https://fedoraproject.org/wiki/User:Adamwill/ Draft_Fedora_privilege_escalation_policy
- to reflect all feedback from this list and from FESco. It will be
reviewed again by FESco next week. Please raise any potential issues or further suggestions for adjustments before then. Of course, even if the policy is accepted by FESCo it will not be set in stone and changes and exceptions can be added in future as appropriate, but I'd like to have it as good as possible at first :) thanks all!
"Directly read or write directly to or from system memory" has an extra (or out of order) "directly".
It's also going to be tricky to run any programs if they can't access the memory in the system. Can the definition be tightened up -- eg. "kernel memory and memory-mapped devices" or "memory other than userspace pages allocated to the current user"?
Rich.
On Thu, 2010-02-11 at 13:32 +0000, Richard W.M. Jones wrote:
On Wed, Feb 10, 2010 at 05:19:59PM -0500, Tony Nelson wrote:
On 10-02-10 15:48:39, Adam Williamson wrote:
Hi, all. So the privilege escalation policy went to FESco, who suggested some minor tweaks and a final run-by the mailing lists before it gets approved.
I have now adjusted the draft - https://fedoraproject.org/wiki/User:Adamwill/ Draft_Fedora_privilege_escalation_policy
- to reflect all feedback from this list and from FESco. It will be
reviewed again by FESco next week. Please raise any potential issues or further suggestions for adjustments before then. Of course, even if the policy is accepted by FESCo it will not be set in stone and changes and exceptions can be added in future as appropriate, but I'd like to have it as good as possible at first :) thanks all!
"Directly read or write directly to or from system memory" has an extra (or out of order) "directly".
It's also going to be tricky to run any programs if they can't access the memory in the system. Can the definition be tightened up -- eg. "kernel memory and memory-mapped devices" or "memory other than userspace pages allocated to the current user"?
Please read the preamble. It specifically (almost painfully) explains the meaning of the word 'directly' and the key phrase 'cause to be excepted provision waived'. When the user runs a program which accesses memory, that's fine - that's 'cause to be performed'. What the provision is attempting to disallow is the user directly examining or modifying the contents of memory. I can make it less restrictive if this is still desired, though. (It's something of a distinction without a difference at present, because a user could of course write a program which runs from their own space which then...accesses memory to which the user is permitted access).
On Wed, 2010-02-10 at 12:48 -0800, Adam Williamson wrote:
I have now adjusted the draft - https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalati... - to reflect all feedback from this list and from FESco. It will be reviewed again by FESco next week. Please raise any potential issues or further suggestions for adjustments before then. Of course, even if the policy is accepted by FESCo it will not be set in stone and changes and exceptions can be added in future as appropriate, but I'd like to have it as good as possible at first :) thanks all!
==> In practice, packages which provide one or more of:
* setuid binaries * PolicyKit policies * consolehelper configurations * udev rules
are likely to be affected by this policy <==
Shouldn't
* D-Bus services on the system bus
be listed there, to make sure that /etc/dbus-1/system.d/*.conf files are sane? It's just that it is quite a commonly used mechanism.
This was brought up in discussion of one of the first drafts, IIRC, so perhaps it is intentionally omitted..?
Tim. */
On Thu, 2010-02-11 at 09:48 +0000, Tim Waugh wrote:
Shouldn't
- D-Bus services on the system bus
be listed there, to make sure that /etc/dbus-1/system.d/*.conf files are sane? It's just that it is quite a commonly used mechanism.
This was brought up in discussion of one of the first drafts, IIRC, so perhaps it is intentionally omitted..?
No, it probably just got lost in the shuffle. Added. Thanks.
On Wed, Feb 10, 2010 at 12:48:39PM -0800, Adam Williamson wrote:
I have now adjusted the draft - https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalati... - to reflect all feedback from this list and from FESco. It will be reviewed again by FESco next week. Please raise any potential issues or further suggestions for adjustments before then. Of course, even if the policy is accepted by FESCo it will not be set in stone and changes and exceptions can be added in future as appropriate, but I'd like to have it as good as possible at first :) thanks all!
I added /dev/shm to the list of directories a user may write to. I believe there was also an item about writing to user mounted file systems, e.g. if a usb device is mounted at /media/disk, but it seems to be gone.
Regards Till
On Thu, 2010-02-11 at 16:16 +0100, Till Maas wrote:
On Wed, Feb 10, 2010 at 12:48:39PM -0800, Adam Williamson wrote:
I have now adjusted the draft - https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalati... - to reflect all feedback from this list and from FESco. It will be reviewed again by FESco next week. Please raise any potential issues or further suggestions for adjustments before then. Of course, even if the policy is accepted by FESCo it will not be set in stone and changes and exceptions can be added in future as appropriate, but I'd like to have it as good as possible at first :) thanks all!
I added /dev/shm to the list of directories a user may write to. I believe there was also an item about writing to user mounted file systems, e.g. if a usb device is mounted at /media/disk, but it seems to be gone.
Added.
I have now adjusted the draft -
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalati... - to reflect all feedback
from this list and from FESco. It will be reviewed again by FESco next week. Please raise any potential issues or further suggestions for adjustments before then.
I just noticed that updating an already installed package no longer is on the list of actions requiring administrative privileges. This was not the case in earlier versions of the policy, which I found correct. The change entered the policy starting from the draft published on February 1. After a quick search, I was unable to find a justification for this change.
IMHO, not every administrator likes to have updates applied by console users. In the (unfortunately not so rare) case of an update that introduces a regression, an unprivileged user without administrative authentication should not be able to perform the update, as this action may change the behavior of the system "as a whole" (I am reusing some words from one sentence in the policy's "Scope" section).
Back in November, I had expressed my concerns on this matter in a comment to the infamous PackageKit bug https://bugzilla.redhat.com/show_bug.cgi?id=534047#c257 My comment and the citation of a previous e-mail by Owen Taylor describe practical scenarios where allowing updates by local users is not appropriate. I guess that due to the flood of comments in that bug, my comment went unobserved. However, it was cited even on http://lwn.net/Articles/371587/ in the context of the "share of pitfalls" of the privilege escalation policy. IMHO, I still think that, by default, only an administrator should be able to update packages, and I think the policy should be modified accordingly. I am aware that an out-of-the-box F12 system allows console users to perform updates, but I would be happy to see this decision reverted in time for F13.
On Sun, 2010-02-14 at 19:42 +0100, Davide Cescato wrote:
I just noticed that updating an already installed package no longer is on the list of actions requiring administrative privileges. This was not the case in earlier versions of the policy, which I found correct. The change entered the policy starting from the draft published on February
- After a quick search, I was unable to find a justification for this
change.
That's correct. This is frankly a 'realistic' decision, on the basis that the PackageKit maintainer believes updating packages should be allowed for a regular user by default and intends to implement this, and I don't want to dictate this decision via the policy (that's not really what we're writing the policy for), so I'd rather just go with PK's choice there.
This is, of course, only a configuration choice, so in any installation you could easily adjust the PolicyKit permissions and stop your users being able to install updates.
On Mon, 2010-02-15 at 12:10 -0800, Adam Williamson wrote:
That's correct. This is frankly a 'realistic' decision, on the basis that the PackageKit maintainer believes updating packages should be allowed for a regular user by default and intends to implement this, and I don't want to dictate this decision via the policy (that's not really what we're writing the policy for), so I'd rather just go with PK's choice there.
The justification I remember for it was that authentication dialogs should be for "exceptional" situations, not for things that might regularly need to occur such as updates, and to avoid lulling users into blinding typing passwords into dialogs every time they are presented just to get stuff done.
Tim. */
Tim Waugh wrote:
On Mon, 2010-02-15 at 12:10 -0800, Adam Williamson wrote:
That's correct. This is frankly a 'realistic' decision, on the basis that the PackageKit maintainer believes updating packages should be allowed for a regular user by default and intends to implement this, and I don't want to dictate this decision via the policy (that's not really what we're writing the policy for), so I'd rather just go with PK's choice there.
The justification I remember for it was that authentication dialogs should be for "exceptional" situations, not for things that might regularly need to occur such as updates, and to avoid lulling users into blinding typing passwords into dialogs every time they are presented just to get stuff done.
What happened to 'ask the first time, and at the same time ask to change the policy to make this action permitted without authentication'? IMO that's the right way. Either the user will be nagged *once*, or else they have said that they want to be nagged.
And... IMO if the policy doesn't require this, then it fails to address the point that was the entire reason for wanting such a policy in the first place.
Matthew Woehlke wrote:
What happened to 'ask the first time, and at the same time ask to change the policy to make this action permitted without authentication'?
PolicyKit dropped support for that. :-(
IMO that's the right way. Either the user will be nagged *once*, or else they have said that they want to be nagged.
I also think that makes sense, but the PolicyKit 1 developers don't. :-(
Kevin Kofler
On Fri, 2010-02-19 at 21:05 -0600, Matthew Woehlke wrote:
Tim Waugh wrote:
On Mon, 2010-02-15 at 12:10 -0800, Adam Williamson wrote:
That's correct. This is frankly a 'realistic' decision, on the basis that the PackageKit maintainer believes updating packages should be allowed for a regular user by default and intends to implement this, and I don't want to dictate this decision via the policy (that's not really what we're writing the policy for), so I'd rather just go with PK's choice there.
The justification I remember for it was that authentication dialogs should be for "exceptional" situations, not for things that might regularly need to occur such as updates, and to avoid lulling users into blinding typing passwords into dialogs every time they are presented just to get stuff done.
What happened to 'ask the first time, and at the same time ask to change the policy to make this action permitted without authentication'?
It was taken out of PolicyKit 1.x. The PK devs consider it a bad paradigm. There's more detail in discussions on that list (going back a ways, I think).
IMO that's the right way. Either the user will be nagged *once*, or else they have said that they want to be nagged.
And... IMO if the policy doesn't require this, then it fails to address the point that was the entire reason for wanting such a policy in the first place.
My reasoning for wanting a policy was to have a clear and central definition of how Fedora intends to handle privilege escalation, not necessarily to impose any tighter restrictions on privilege escalation than were previously informally practiced.
-
Adam Williamson -
Davide Cescato -
drago01 -
Kevin Kofler -
Matthew Woehlke -
Richard W.M. Jones -
Till Maas -
Tim Waugh -
Tony Nelson