Security policy oversight needed?

[Gregory Maxwell]

On Wed, Nov 18, 2009 at 7:37 PM, Mike McGrath <mmcgrath at redhat.com> 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)