Fedora 12 Package Installation Policy Tightened 172
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."
Attitude (Score:5, Insightful)
Dunno man, but (Score:5, Insightful)
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.
A sensible compromise (Score:4, Insightful)
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.
Re:Finally! (Score:3, Insightful)
they havent fixed it yet
Re:Finally! (Score:1, Insightful)
I actually think the devs originally had it right to some degree. At least the problem they point out is real:
"From a more general perspective, the end effect of putting up a lot of
dialogs:
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."
Most of the times I have fixed a worm infested windows machine of a friend it wasn't an exploit that was to blame but the person had installed it themselves. Devs have trained users to respond to a password box in the following way: Type in their password and press enter.
Now if my flatmates/friends were used to installing software from the official repos without being prompted for root then if they were prompted it would have some effect. Possibly make them give me a call first.
Re:Overreacting (Score:3, Insightful)
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)
Re:Attitude (Score:3, Insightful)
To be honest that's kind of what I've come to expect from most FOSS projects - an attitude of "we're doing this because we want to, we donate our time for free - if you don't like it, fork it and fix it, or use something else".
It's actually hard to argue with most of the time, as they really are donating their time for free...
Re:That was close... (Score:3, Insightful)
I hope they start signing beta packages with beta keys in the future...
Re:To quote Richard Hughes: (Score:2, Insightful)
* "It's not insecure. We've had the mechanism checked. The default policy may not be to your taste, but this is the "desktop" spin, not the "server" spin. " (Fedora = Desktop, RHEL/CentOS = Server)
* "You either trust the Fedora repos or you don't." (This is true. Either you trust Fedoraproject to keep malicious packages out of the repos, or you do not. Therefore, a trust of the default repos wouldn't be so bad)
* "I don't particularly care how UNIX has always worked." (A little bit of a troll, but Linux has no qualms showing that they deviate from Unix (LSB, for example.)
* "You missed the "in my opinion" line in your reply." (Troll)
* "There are other, *easier*, ways of rooting the system. " (true)
He has some valid points. I thought the idea was a good one, but I suppose I'm in the minority.
Re:To quote Richard Hughes: (Score:3, Insightful)
I don't see how most of those quote could be considered trolling, but especially this:
# "There are other, *easier*, ways of rooting the system. "
That's totally accurate. The policy previously allowed users who were logged in to the local console to install signed packages from a repository. No one would claim that there are no security vulnerabilities in packages within the default repositories, but they tend to be fixed very quickly after they are found, so the window for exploit using this mechanism is extremely small. People do have legitimate reasons why they wouldn't want this policy (in shared PC environments), but security is hardly one of them. Users who have physical access to a computer can compromise it far more easily than waiting for a vulnerability to be found in a package that isn't installed, installing that package before an update is issued, and exploiting the vulnerability.