Re: Final (hopefully) privilege escalation policy draft
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 Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
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. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
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 1. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
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. 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
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_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! == 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. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
On Wed, Feb 10, 2010 at 11:19 PM, Tony Nelson tonynel...@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 ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
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_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! 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 pgpXHVGiVX6vK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
On Thu, 2010-02-11 at 13:32 +, 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). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Final (hopefully) privilege escalation policy draft
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! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
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. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
