Fedora's privilege escalation policy proposal [LWN.net]

By Jake Edge
February 3, 2010

Back in November, when Fedora 12 was released, there was something of an uproar over a new feature that allowed unprivileged package installation. While there are differing opinions on how sensible it was to add that feature, Fedora developers would much rather argue about that before a release is made—rather than shortly after, as happened with Fedora 12. To that end, Adam Williamson has been drafting a "Fedora privilege escalation policy" that seeks to clearly identify the types of package behavior that should either be avoided for unprivileged users, or undergo more thorough review.

There are two principles to guide the policy, which essentially encapsulate the idea that unprivileged users should not be able to "break" things for other users:

An unprivileged user without administrative authentication must not be able to change the behavior of the system "as a whole" (as viewed by other users or by network clients), unless the system behavior is intended to be dependent on the actions of the unprivileged user.

An unprivileged user without administrative authentication must not be able to bypass or override other users' reasonable expectation of privacy of their data, where "reasonable" is limited by what computers can do, what Linux can express, AND explicit actions by the "other user" to configure access permissions.

The policy then gives examples of package elements that are likely to make a package subject to the policy, such as setuid programs, PolicyKit policies, or udev rules. It also lists nearly two dozen actions that should only be allowed for privileged users. Privileged users, for the purposes of the policy, are those that authenticate with the root password, use sudo if that is configured by the administrator, or are the first user account added—without an additional password check—for approved Fedora spins that grant administrative privileges to that account. The latter is in keeping with the idea of a "desktop spin" that would be targeted at single-user systems, where the user and the administrator are one and the same.

The list of privileged-only actions is fairly comprehensive. Earlier drafts, like one posted to the fedora-testers mailing list, were discussed with additions and wording changes made. One somewhat puzzling omission is the ability to upgrade an installed package. Though it appears as a privileged operation in an earlier draft announced on fedora-devel, that was an oversight, which Williamson corrected. The PackageKit policy for Fedora 12 allows unprivileged upgrades, and the intent is to continue that policy.

Allowing unprivileged upgrades, while much less potentially dangerous than the original Fedora 12 policy, still has its share of pitfalls. Allowing regular users the ability to upgrade assumes that security vulnerabilities are not introduced in package upgrades. It may also run counter to an administrator's policies as Davide Cescato points out in a comment on the original Fedora 12 bug:

On the machine I maintain there are currently a couple of updates that I do not want to carry out, since I know that they lead to regressions or undesired side effects. I can as well think of an administrator who only want to perform security updates, or of an administrator who prefer to pick updates selectively. In such cases, a local user who performs all available updates effectively "spoils" the administrator's work.

Overall, though, the policy is well thought-out and covers the kinds of problems that new or updated packages might cause. There has been some resistance to the enforcement and approval elements of the policy, but that seems to be based on a misunderstanding. The intent of the policy is that new mechanisms which affect privileges need review, not new users of existing mechanisms (such as PolicyKit, kdesu, etc.). As Miloslav Trmač put it:

You are not required to announce / ask for approval of every new DBus server - but if you want to introduce another program that allows running something as root (new DBus, new sudo, ...), _that_ requires approval / announcement of changes.

The purpose of these announcements is to allow the QA team and people working on Fedora security to maintain a list of such mechanisms. If the QA team or someone working on security knows there is userhelper or DBus, they can search for packages that use it, and check the configuration of the packages, do code reviews etc. If they don't know about the mechanism, they can't check the users of the mechanism are secure.

As a set of guidelines to help packagers, testers, and reviewers, the proposed policy is quite useful. Williamson plans to present the draft to the Fedora board at its meeting on February 9, so it may become Fedora policy in the very near future. Beyond that, though, it would also be a good starting point for other distributions that are considering policies to help tighten up the security of their packages.

(Log in to post comments)