Thank you greatly for the well worded and well thought out response/update on the situation. In a thread of what was essentially a flame war, it is nice to see something constructive and meaningful emerge from the ashes.
-Adam (From Android - CM)
On Nov 19, 2009 8:30 PM, "Owen Taylor" <otaylor@xxxxxxxxxx> wrote:
I wanted to provide an update to the list on the current thinking about
the PackageKit policy issue from the perspective of the people working
on the core desktop packages and on the desktop user experience.
There was informal meeting earlier today with Richard Hughes, and
myself, and a couple of people who could provide help with big-picture
Fedora issues like Bill Nottingham and Jesse Keating, to try and figure
out if there were obvious steps to take in the short term.
Obviously there are lots and lots of people who care deeply about this,
and there are discussions that need to continue, but with the delay in
getting packages built, tested, and pushed out, we thought there were
advantages to jump-starting things. If there was something obvious, then
it made sense for the package maintainer (Richard) to just do it.
I'm writing this mail somewhat by default: the people who really matter
are the maintainers of the relevant packages, but Richard has gone to
bed, and David Zeuthen and Matthias Clasen are on vacation this week.
I'll try to reflect what they would say; much of it is certainly my own
personal take on things instead.
- Owen
Where the Fedora 12 policy came from
====================================
In Fedora 9, 10, and 11, the first time a user tried to install a
package from the Fedora repositories, they would be prompted for a root
password, with a checkbox to remember that permission for the future.
(Before Fedora 9, you had to enter the root password every time.)
We weren't really fully happy with this; this was basically asking the
user to construct their own security policy. And not only that, but do
it dialog-by-dialog, permission-by-permission as they tried to set up
their Fedora system and get on with their life.
>From a more general perspective, the end effect of putting up a lot of
dialogs:
+-------------------------------+
| |
| < A complicated explanation > |
| |
| Root password [ ] |
| |
| [ OK ] |
+-------------------------------+
is that you are training users to blindly enter the root password and
hit OK, *not* something that enhances the overall security of the
system.
There is an obvious better way to do this, which is to figure out
what the appropriate roles are for the system: adminstrative users,
non-adminstrative users, etc., and let the person maintaining system
decide who gets what role.
So, David Zeuthen did a major redesign of PolicyKit to move it from
the old "remembered permissions" policy, to a model where users could be
assigned different roles. See:
https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html
For some more details about how it works.
The idea was that the change in PolicyKit would be accompanied by a
default set of roles, and a nice user interface for assigning users to
roles. Unfortunately, with the constraints of time, it became clear that
this all (and especially the GUI) wasn't going to be there for Fedora
12. So, PackageKit needed a fixed policy for all users. For each action
(install signed packages, install unsigned packages, remove packages,
etc.), it needed to allow, deny, or ask for the root password.
Among the decisions Richard made was allowing all users to install
signed packages from the Fedora repositories. This was clearly the right
behavior for the common case of a single-user system, where the only
user is also the administrator. And it seemed pretty safe: Fedora isn't
supposed to have packages in it that are dangerous to install. (For
example, by policy, all network services must be off by default and not
enabled by simply installing a package.)
The reaction (why that probably wasn't the best choice)
=======================================================
There's obviously been a lot of feedback on this list and in other
forums about this approach. And a lot of good points have brought up.
Probably the most important one is a bit obvious in hindsight: Fedora is
used on a wide variety of systems, and in some of those - like a shared
home system with parents and young children, or like a computer lab
system - there are some users who shouldn't be able to change what is
installed on the system. Even if installing those packages isn't a
security hole.
The other thing that is clear from the discussion is that we didn't do
nearly enough communication about the change. I think was partly because
the changes *weren't* finished. A rewrite of PolicyKit wasn't a feature
in itself; the feature would have been the accounts dialog, which we
didn't do for Fedora 12. But clearly the changes we did do had some
major impacts that needed to be advertised.
And while there are great low-level docs with all the details about
PolicyKit configuration (see polkit(8) for a starting point to the
docs), we didn't have the simple instructions for changing basic system
policy.
Moving forward from here
========================
After talking things through a bit, the consensus was that we need to
take a course that's conservative for Fedora 12. To do something that
is safe for almost all uses of Fedora, if a bit less convenient.
So, what Richard is planning is an update to PackageKit that changes the
policy so that the root password will be required for package
installation. We should have this out in fedora-updates quite soon;
hopefully tomorrow.
Once we get that out, we'll also make sure that there is documentation
available about how you can configure some users to be able to install
software without having to type the root password every time.
In upcoming Fedora releases, we expect to finish both the default set of
policy roles and the user interface components to provide the full
experience that was originally planned.
Executive summary
=================
We'll make an update to the F12 PackageKit, so that the root password is
required to install packages.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
