Package Manager Denies Permission to Install

[Jeff Spaleta]

On Wed, Jan 21, 2009 at 2:59 PM, Kam Leo <kam.leo at gmail.com> wrote:
> The fallacy is believing you automatically obtain security by auditing
> applications running on X for execution by the superuser or preventing
> root from logging into X.

No one is suggestion that you automatically get security. Security is
not a yes/no proposition. It is a set of steps... it is a
process...like any risk management process.  Anyone who has had
industrial safety hazard training in the brick and mortar world will
have these sort of concepts beaten into their heads..before they get
to turn on the class 4 laser.

What is being suggested is that privilege separation as done by
policykit is a way to reduce the risk of exposure caused by the human
errors in writing computer code.  The smaller the codebase which must
run privileged the more limited the risk exposure for certain types of
software flaws.

What is an acceptable risk for some people, is too much risk for
others and vice versa. This will always be true. A default
configuration must be chosen and we must accept that default
configuration will never be the correct configuration for everyone in
terms of risk aversion.

The question becomes how flexible is our system in allowing for
riskier activity if the local admin so chooses via reconfiguration and
how much risk aversion is hardwired?
Certainly gdm can be reconfigured as its a pam configuration file to
prevent root login. Which is the whole point of using pam..as it is
locally reconfigurable policy and not hardwired into gdm itself.

Is PolicyKit reconfigurable? Yes, you can do policy grants and
customize PolicyKit authorization behavior. Do people know how to do
that? Probably not.  What we have fallen down on is communicating how
to customize PolicyKit based authorization for those people who have
local admin needs not covered by the defaults.

-jef