Slashdot Mirror
Fedora 12 Package Installation Policy Tightened
AdamWill writes "After the controversy over Fedora 12's controversial package installation authentication policy, including our discussion this week, the package maintainers have agreed that the controversial policy will be tightened to require root authentication for trusted package installation. Please see the official announcement and the development mailing list post for more details."
It's about time they fixed that.
Ask Slashdot: Where bad ideas meet poor googling skills.
What really got me about this one was the attitude some developers had ... constantly trying to justify their correctness, despite the huge backlash from users. I feel the trust relationship is kinda broken ... but at least they finally came around and listened.
See personally I never thought it would be in discussion whether to allow non-root users to install packages. In my opinion it's one of the great advantages of *nix systems as far as security goes. Even the distributions with the root user disabled to make it easier on a desktop user, like Ubuntu, still require use of the sudo command. It's one of the biggest reasons certain worms and drive by download techniques which crippled Microsoft OS's never worked on *nix systems.
Even those with good senses of humor, honor, and saintly intentions must occasionally require the use of a strong shield
The whole Fedora Team's creation of and response to this issue creates very serious doubt in my mind about their ability to manage a distribution and their understanding of proper security policy. I think they've got to open up their decision making process more and learn to communicate better. An idea this bad should have been squashed 5 minutes after it was proposed instead of being allowed to actually make it into a released distribution.
At least it all shows that the community still ultimately calls the shots.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
This is just nonsense, TOTAL NONSENSE.
Unix users have ALWAYS had the ability to install applications into their own home directory. Ok, so it (maybe) never occured to the authors of Linux package managers to target the users home directory. However, the fact remains that the ability/possibility has always been there. You simply don't need to pollute the system files in order to "install an app" on Unix. That is one of it's key strengths.
This is why the Fedora guys got skewered.
Some of us have been "installing applications" in our home directories since before the first line of Linux was written.
A Pirate and a Puritan look the same on a balance sheet.
Seriously, it's not like the final release was a surprise. Non of the beta testers noticed it and thought it might be an issue?
How would they? Beta packages are unsigned, and this thing only works on signed packages.
TROLL:
Allowing users to conveniently install signed/authorized packages/software.This is LINUX dammit if you're not jumping through hoops to get something done you are DOING IT WRONG!.
RANT:
Non-root users will destroy EVERYTHING that's why they must be frustrated for the sake of SECURITY. That white-listed signed software package must be personally allowed by the head of IT before installation can complete!
QUOTE:
If you give up freedom for security you deserve neither - Thomas Jefferson -
SENSIBLE RESPONSE:
Fedora caved in to a knee-jerk reaction. The compromise should of been allowing admin's to white-list a subset of the signed packages that they want to allow all users unrestricted access to. The year of unnecessary security is upon us.
To quote Richard Hughes, the developer responsible for the braindeadness in the first place, and repeatedly trying to brag his competency of being a dickhead in the bugzilla(https://bugzilla.redhat.com/show_bug.cgi?id=534047).:
Source: http://blogs.gnome.org/hughsie/2009/09/23/linux-is-about-choice/
It seems that he interpreted his own words as "Just because you can do something, doesn’t mean you should do it. But for me, I can fucking make whatever 'choice' and screw everybody else. Bwahahaha!"
And his recent rants:
(Source: http://blogs.gnome.org/hughsie/2009/11/20/the-fedora-12-installing-saga/)
But he was the one who was being a troll first. Quotes from the bugzilla:
Now, I'm wondering how on earth did someone got a job for being a devtroll. Red Hat pays him to develop, but trolling the bugzilla? I don't remember anyone "attacking him personally" on the bugzilla. I wasn't following the mailing lists though.
And he now seemed hurt because the users actually bothered to donate their own time correcting his mistake.
Grow up.
Notice that the announcement said:
> The update will require local console users to enter the root password to install new software
packages.
This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.
This is the sort of linguistic sloppiness that lead to the shrieking by users. While such inconsistent behavior for the console versus logged in SSH users has no reasonable excuse and shouldn't have happened, the danger was much less than the early explanations lead reasonable people like me to believe, because many of the discussions left out the "this only works from the console" part. And given that the new Fedora release is taking a bit of time to download, we hadn't had the chance to try this ourselves.
The policy of allowing certain users to install software, within certain limits, is not crazy. It gives you:
* don't have users typing in the root password all the time
* if you need a codec or viewer plugin, the system can pop up a "Getting a viewer for you" window, rather than a "Can't view this, please install foo, put root password here"
* this is made possible because Linux distros have their own "app store" of approved software, which comes *from the distro* so you know where to get it and you know it's relatively unlikely to be malware. Windows and MacOS can't do this.
The limits included only giving these privileges to the console user, who probably has physical access and can root the machine anyhow, which is also sensible. But it also gives malware the local user might end up running (e.g. due to a Firefox compromise) the ability to install software. That's not necessarily too bad unless it's, for instance, installing vulnerable setuid-root software. So this needs to be thought about carefully before enabling on an individual machine, unless the distro has thought *even harder* about it so you don't have to. It doesn't really seem like the Fedora guys thought about it hard enough, even though it could be a good policy for the future if done right. And I don't think anybody is happy about such a major change in behaviour happening without it being announced and debated very publically.
I hope to see this feature reappearing in a future Fedora release - it's a good feature if they do it right. But they should be *even more* careful about what they permit and they shouldn't make dramatic behaviour changes occurring by default without heavy debate (and if you upgrade from an old version, rather than clean install, it should certainly say "This is a behaviour change, do you want it?" - probably defaulting to no.
It wasn't "everyone and their dog". You basically had to be logged into the console. I confirmed that it didn't work via a normal SSH session last night, the first time I had access to a Fedora 12 machine, was confused by it, and resolved to look into it later. The announcement helped explain what I saw.
It was still a stupid move, but it explains why more people wouldn't have noticed it in beta testing: we'd have often been logged in via SSH from our desktops. The stupidity was in introducing a distinction between console access and remote shell access: it's an unnecessary finessing of the console login that just created confusion and a tempest in a teapot that wasted people's time.
What about installing finger/telnet/etc?
What about installing sendmail and conflicting with the postfix installation?
What about installing 1Gb of maps for some random game?
What about updating a package that the admin knows will generate a conflict with other in-house application? (I don't know if updates were included in the policy, but is the same criteria)
This is a good lesson in why a beta/staging environment should be as close to the real stuff as possible.
I hope they start signing beta packages with beta keys in the future...
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
In which case I've lost my mind and apologise. I took the first RPM from rawhide 0xFFFF-0.3.9-4.fc12.x86_64.rpm and tested to see if it was signed. It was, but this doesn't seem to be universal, so you're right, and I'm entirely wrong.
Most packages in the current 'Rawhide' are still packages from the final F12 release, and hence signed. If you check a package with an fc13 tag - i.e. one built since F12 went out - you'll see it's not signed. There was a full package set rebuild during the F12 cycle, before the beta release, so by the time F12 Beta came out, just about every package in Rawhide had been rebuilt since F11's release, and hence was unsigned.