Hi Adam, On Fri, Jan 29, 2010 at 5:27 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote: Agree it makes sense for there to be a policy, thanks for looking at this! So a general theme that seems to run through the policy of "don't affect other users", and some things have exceptions (shutdown and reboot), but others don't (change the system time, adding new software). Is there a rationale for that?

On Sat, Jan 30, 2010 at 1:20 AM, Adam Williamson <awilliam(a)redhat.com&gt; wrote: Ok, actually "one time" feels like there's a more general principle at work here, which is the degree to which the operation could potentially affect other users. For example, there's a pretty wide gulf between "install new desktop app" (other users see a new menu entry) and "start or stop system daemons" (can easily break printing, networking, or just crash the. Changing the system time is in between there. The reason I mention this specifically I'd like in the future to widen this set a little bit for the "self managed" desktop target (i.e. livecd download), specifically include at least "install new desktop application from " and "initiate system update" in that set of default privileges. Maybe the way to think of system update is that the system comes by default configured to update, and the privilege is actually to optionally delay the update. I think it's very important that we make typing in the root password dialog a meaningful event, something that means "you are doing something really unusual, are you sure?", like turning off SELinux. If we require it for simply installing Firefox security updates it greatly dilutes the warning/danger value of it. So as long as we don't view this current list as written on stone tablets but a flexible system (more in the sense of guidelines/examples), subject to revision, I'm fine with it.

Adam Williamson wrote: The current PackageKit policy in F12 updates still allows upgrading (as opposed to installing or removing, not sure about downgrading, does PackageKit even support that?) packages without root authentication. Is this intended to be changed as part of the proposal or should the proposal be fixed instead (just remove "upgrade" from the sentence)? Is the bureaucracy in this section really necessary? AFAICT what was missing when the F12 PackageKit change was made was the informative part of the proposal, the maintainer just didn't know what he should be allowing and what not. I don't think the enforcement part is really needed, maintainers should be able to get it right on their own given the detailed list of evil things to avoid which the proposal provides and I haven't seen any evidence as to the contrary (again, the PackageKit example is not applicable because the PackageKit maintainer did NOT have such a list to go by when he made his change; there's no reason to believe he'd have made that change in spite of it). Kevin Kofler

Adam Williamson wrote: Right now we're in a phase where a lot of stuff (system-config-*, several parts of KDE and some other stuff) is getting ported from running the whole app under consolehelper or kdesu to PolicyKit mechanisms. This is generally seen as a *good* thing. It'd be really annoying to have to go through a FESCo vote for every single one of those. At the very least, I'd suggest adding the following clause to that paragraph: "Any mechanism which requires administrative authentication to perform the privileged action (e.g. auth_admin policy in PolicyKit, kdesu etc.) is NOT a privilege escalation mechanism for the purposes of this paragraph." Rationale: Such a policy does not impact the system's security as you have to enter the root password before doing anything dangerous, so none of the invariants under "Requirements" can be violated. And additionally, you can always as a user run the whole app under e.g. kdesu and thus "escalate your privileges" using the root password, so it doesn't make sense to police apps providing such a mechanism. What really matters for security is what you can do WITHOUT the root password. This is not really clear from the policy as written now, adding the suggested sentence would clarify it. (That said, I don't see even the clarified policy as being necessary. We have a set of guidelines, maintainers should follow them, why do we have to police them? As I explained before, there is no evidence that this is necessary or useful. The PackageKit issue was caused by lack of a policy, not lack of enforcement.) Kevin Kofler

Miloslav Trmač wrote: Oh, if that's the intent, that's of course perfectly fine. I'd be happy to provide any needed documentation about KAuth, but you'll only really need it if you want to run checks on the source code, as KAuth uses existing mechanisms (PolicyKit (both 1 and 0.9 are supported), D-Bus activation) for the actual privilege escalation, it's just a source-level abstraction layer (so for example, you won't find a PolicyKit policy in the source code, but a KAuth policy which is converted to a PolicyKit policy at build time). Kevin Kofler

On 30 January 2010 07:33, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote: No, PackageKit won't let you downgrade a package. Sure, if there was a policy document I would have never made the Fedora change in the first place. I still think the original change (to make signed packages installable by the local console user install without a password) is the "right" upstream policy, but I will of course ensure all my packages agree with whatever Fedora policy is decreed. Luckily, with the new user account editor planned for F13, a lot of these PackageKit security policy choices can be made more intuitive. Richard.

On Sat, 2010-01-30 at 10:52 +0100, Till Maas wrote: It means that it's okay for the user to indirectly cause changes to happen, because that happens all the time. This particular clause applies only to direct user actions. full list of directories it's okay for an unprivileged user to write to directly would be good... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net