On Wed, Nov 18, 2009 at 7:37 PM, Mike McGrath <mmcgrath@xxxxxxxxxx> wrote: > I think that's too subjective though. I'd be more in favor of a simple, How is this subjective? At one time it was the norm that you had to justify a SUID 0 binary. Packagekit is basically allowing the same thing through other means. It should be subject to at least the same scrutiny. > broad view of what the user should be able to do without root. It's > possible "install packages" would be on that list, it's possible not. > That way packages could ask themselves "does this break the policy?" If > it doesn't, great. If it does, time for a bug report. > > Better then a review process because then everyone would generally know > what to expect. Some kind of review and disclosure should still be required because security holes can be astonishingly difficult to spot as bugs, yet utterly trivial to exploit. The time configuration policy is actually a fantastic example of this: After it was pointed out that any user could change the time willy-nilly the complaint was disregarded and denied by many because the dialog *did* ask for a password, as would be the classic unix security model expectation. Except… it was asking for the *users* password rather than a root password— so if you happen to know both (or if they are the same) you could test it and fail to realize that it was violating the long-standing expectation. There is also the significant possibility of policy interaction. A sufficiently general policy (i.e. one which isn't just the policykit policy) could possibly permit configurations which are acceptable in isolation but which are hazardous in practice. E.g. perhaps one policy permits the install of packages from pre-configured repos and another policy permits the user to add repos (to make it easy to navigate them in the package management interface). (Not the adding packages from existing repos isn't already a terrible security hole: Unless you have very specific rules about the default configuration of packages in the repo it's likely that some of the packages will violate the security expectations when installed) -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
