Friday, November 20, 2009

Why developers suck as admins

So Fedora 12 allows regular users to install packages as long as a) the user is logged in on the console, and b) they are signed and from a trusted repository.

I think it's great that we can enable this functionality, and I'd even argue that it should be on by default on the Live spins (and installs from the Live spins), but in the general case this is a horrible idea.

I've seen a few arguments why this doesn't matter. For example, anyone with local console access already owns the box, right? Well, console access != physical access. Think, well, anything in a server room (systems in locked cabinets attached to a KVM, or virtual machines). While this gives more ammo to us old-timers for not putting X on our servers (I'm looking at you, skvidal), the reality is that it's not realistic to expect all servers to run without a GUI.

I don't want to re-hash the whole (long) thread linked to above, but I think it is important to point out some of the solid reasons why this change is a bad idea.

  • The installation of one package shouldn't change the behavior of the system. (This one package changes the behavior of the system, plus allows for other packages to be installed that could do the same.) If you take into account that unintended dependencies tend to pull in random stuff during upgrades, this becomes especially important.
  • Can we really guarantee that there are no signed packages available that are exploitable, all the time?
  • This is a major change in behavior from Fedora 11 that did not go through the Feature Process, unless I'm missing something.
  • Possibly even worse, if this "feature" makes it into RHEL 6, you run the risk of a lot of semi- and non-technical sysadmins having yet another security decision made for them, probably without their knowledge. (How many are aware of ctrl-alt-del, console users being able to shutdown/reboot, grub allowing kernel options ("single", for example) unless you set a password, etc.? Of course I've never understood the logic of all of that being open, but magic sysrq being off by default.)
  • At the very least, this is a DoS attack vector, although more likely due to somebody screwing up and installing a bunch of packages rather than somebody intentionally trying to fill /, /usr, or /var.

Oh, and about the title... Developers of software get stuck into a mindset of "make my software work, no matter what", and, on a related note, tend to have tunnel vision about the use cases for their software. One of the things I love about Fedora is that we have a lot of sysadmins who happen to be coders, so we tend to find a good balance between "usability" (AKA letting the developers go nuts) and maintenance/security. This one slipped by us, but I hope the decision will be made to push an update with a more sane default. [Update: It was.]

4 comments:

AdamW said...

"This one slipped by us, but I hope the decision will be made to push an update with a more sane default. "

It already was.

https://www.redhat.com/archives/fedora-announce-list/2009-November/msg00012.html

https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html

Steven Pritchard said...

Very nice.

Luya Tshimbalanga said...

Now that I have fully read and study the case, the incident is a classic example of failure of communication. There is not a problem with the functionality. (Credit for GeneralZod from linuxfr.org for detailed information)

* The installation of one package shouldn't change the behavior of the system. (This one package changes the behavior of the system, plus allows for other packages to be installed that could do the same.) If you take into account that unintended dependencies tend to pull in random stuff during upgrades, this becomes especially important.

It is actually policies change from Freedesktop discussed on mail list six months ago. The maintainer of PackageKit only applies it and only concerns local users. Note that behaviour only applies for signed packages from trusted repositories i.e. you already imported their keys.


* Can we really guarantee that there are no signed packages available that are exploitable, all the time?

That is social-engineering in this case. The policy perfectly worked on rawhide and Fedora 12 Beta because you still need authorization from root to install unsigned packages or when you import keys after you have installed a repository for the first time. It is only with signed packages that behaviour occurs with PackageKit on desktop environment.

The incoming feature of Fedora 13 only reinforces the original policy from Fedora 12.

skvidal said...

old timer?! I'm 33!