7145316
story
Comments: 172 +- Linux: Fedora 12 Package Installation Policy Tightened on Friday November 20, @08:52AM
Posted
by
kdawson
on Friday November 20, @08:52AM
from the tougher-by-default dept.
from the tougher-by-default dept.
background: url(//a.fsdn.com/sd/topics/topicredhat.gif); width:60px; height:53px;
redhat
background: url(//a.fsdn.com/sd/topics/topicsecurity.gif); width:59px; height:78px;
security
background: url(//a.fsdn.com/sd/topics/topicunix.gif); width:80px; height:57px;
unix
background: url(//a.fsdn.com/sd/topics/topiclinux.gif); width:60px; height:70px;
linux
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."
Related Stories
Necessity is a mother.
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.
Finally! (Score:4, Funny)
Re:Finally! (Score:5, Funny)
I liked for the ability for users to manage my box.
Surely the users would never do anything that would harm the system in which we all exist?!?
Parent
Re: (Score:2)
Re:Finally! (Score:5, Funny)
It took like a whole 24hrs from when a story was posted on slashdot.
What are they Microsoft?
Bunch of dirty hippie linux slackers
Parent
Re: (Score:3, Insightful)
they havent fixed it yet
Re: (Score:2)
It (or similar) has been showing up on pretty much every story I've read on here for the last few days.
Attitude (Score:5, Insightful)
Re:Attitude (Score:4, Interesting)
Nonetheless, it's not a *horrible* concept, it was just a little too loose (as I've seen it described).
I think, as an option, and if the user was within a certain group (such as sudoers/wheel/whatever - changeable by the admin, and users who have administrative access), and only signed packages were affected (no change there), I wouldn't see an issue. At that point, it's basically saying "don't require a password for sudo when installing a package trusted by trusted authority 'xyz'".
Parent
Re: (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: (Score:3, Interesting)
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.
Fedora does this all the time (or at least, often enough for me to think it's all the time). Here is a couple of examples:
That was close... (Score:2)
...the package maintainers have agreed that the controversial policy will be tightened to require root authentication for trusted package installation.
Wow. Thank goodness those guys "discovered" that allowing non-root users to do dangerous things to the OS/application stack was a bad idea and "agreed" to lock it down. We might have had some serious problems there. (roll eyes)
WTF? How on gawds green earth did this happen in the first place?
Re: (Score:2)
WTF? How on gawds green earth did this happen in the first place?
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?
Re: (Score:3, Informative)
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.
Re: (Score:2)
Not that I have a Beta to hand to check this, but you're saying that they sign Rawhide packages, but don't sign Beta packages? I find this highly unlikely, to the extent I'd guess you just made this up.
Re: (Score:2)
Not that I have a Beta to hand to check this, but you're saying that they sign Rawhide packages, but don't sign Beta packages? I find this highly unlikely, to the extent I'd guess you just made this up.
At what point did I say that they sign Rawhide packages? They don't.
Re: (Score:2)
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.
Re: (Score:3, Informative)
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.
Re: (Score:3, Insightful)
I hope they start signing beta packages with beta keys in the future...
Non-controversial (Score:2)
Wow. Thank goodness those guys "discovered" that allowing non-root users to do dangerous things to the OS/application stack was a bad idea and "agreed" to lock it down. We might have had some serious problems there. (roll eyes) WTF? How on gawds green earth did this happen in the first place?
The use of the word "controversial" to describe the rollback to the original, more secure settings is bizarre, too. The failure here was the process and the people that must have worked to push through the weird settings that allowed everyone and their dog to install random 'signed' but unconfigured packages. That's something we'd expect from Microsoft employees, trainees, 'engineers' or 'researchers', not Red Hat staff or volunteers.
I notice that mono has shown up in the distro, too. When will manage
Re: (Score:3, Informative)
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
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.
Parent
Re: (Score:2)
Never really thought this needed changing (Score:5, Interesting)
Re: (Score:2)
Bullshit. Worms need not require a privileged user account to be effective. A process running as an unprivileged user can:
Re: (Score:2)
You have to admit, it's pretty hard to know in advance which distro you're on and which packages are going to be available, so you have to plan to try a whole pile of exploits before you find one that works. The biggest or most common vulnerabilities are usually found, fixed, and ready for update rather quickly, so the window of opportunity is smaller as well. If the attack fails, you're restricted to listening on high ports and any other potential damage is minimized.
So I'd say the fragmentation "problem
Re: (Score:2)
Maybe. But diversity isn't so important when you have one or two very popular targets. And some distributions' packages have modified version information identifying the distribution. For example, Ubuntu's Firefox build includes the distribution name and version in the user agent. Furthermore, many
Re: (Score:2)
The first entry is not entirely true. Non-root processes are restricted from using low port numbers(1024, iirc). Also, if there's a correctly configured firewall on the machine, a non-root process is incapable of going around it.
Not that it would actually prevent any malware I know of from wreaking havoc, high port numbers are perfectly fine for sending email and talking to bot herders.
Re: (Score:2)
I wasn't concerned about listening, actually, just outgoing connections.
How many desktop Linux users have firewalls that prevent untrusted processes from making outgoing TCP connections?
Re: (Score:2)
Non-root processes are restricted from using low port numbers(1024, iirc).
And? Just because SMTP servers traditionally listen on port 25 doesn't mean that my zombie mailer process has to; similarly clients making outgoing connections all use high-numbered ports anyway, whether they're malicious or not.
if there's a correctly configured firewall on the machine, a non-root process is incapable of going around it
Not entirely true - you can make a connection out to a known address, and have the controller on the
Re: (Score:2)
That's true, and that's my point. It is the contents of user accounts that users care about. The difference between "a worm stealing all of a user's personal information, leading to identity theft" and "a worm stealing all of a user's personal information and breaking the operating system" isn't that significant after the user's per
Re: (Score:2)
I agree with you completely that requiring root or sudo access is a good thing but the beauty of Unix and Linux is that I can install software without root privileges rather easily. Whether I extract a tarball into a fakeroot directory in my home dir or specify the same with rpm (or an rpmmacros file), it's usually trivial to install packages. What's not so trivial is to change the configuration of the host system. And I agree with you completely that requiring root or sudo access is a good thing.
This mea
At the risk of being flamed to hell (Score:2)
The idea of allowing normal users to install signed software is actually not all that bad.
Frankly, the most common alternatives - either users have to ask IT to do it (which neither the users like nor does the IT department necessarily want to spend its days messing around with) or giving them local admin (or, this being Linux, local root) privileges are both awful.
Off the top of my head, I can think of a few sane solutions to the problem - none of which appear to have been given serious thought:
1. Provide
Re: (Score:2)
It is a horrible horrible horrible default. Provide the capability so those infrastructures that really want it can make an *informed* choice to do so, fine.
You don't have to give people *full* root privileges, you can selectively give them access through sudo to use a package installer that only works with signed packages. Though fedora emphasizes 'su' style privilege escalation which has no granularity, 'sudo' style gives the granularity required. The credential of 'oh, I happen to be at the 'local' sc
Re:At the risk of being flamed to hell (Score:5, Informative)
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.
Parent
Re: (Score:2)
This is by far the best comment in here.
Thank you for thinking outside that tiny box of a coming-from-windows mindset, that so many “new” people wrapped themselves in in the last years.
The saying “Those who do not learn the history, are doomed to reimplement it. Badly.” fits perfectly here.
It’s the same set of people who work so hard, so make KDE and Gnome virtually indistinguishable from the incredibly primitive UI of Windows. (In case you don’t know: Everything that sti
Re: (Score:2)
I have one word for software which can be installed without root privelege:
ActiveX
Re: (Score:2)
I'll dive in burn with you on this one. You missed one other major point that the Fedora developers had. A large majority of their user base is desktop systems where there is not some great IT staff or distant administrator. I am the admin in my boxes. No one else has a login. If I want to install packages without a password that shouldn't be difficult. I configured the repositories, I added the public keys after evaluating how much I trusted the repo. Letting the normal user (still me) install packa
KPackageKit (Score:2)
I have a similar complaint about KPackageKit. You can optionally choose to make it store your password so that you don't have to type it in when you next install or update packages. That's fair enough, if you trust that no one is going to install anything dodgy then that's OK. What I do take issue with is that this box is checked by default.
Granted I imagine most people might simply click this anyway but am I the only one who thinks this is a bit of an oversight?
Outrageous (Score:3, Funny)
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: (Score:4, Informative)
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 [redhat.com]).:
Source: http://blogs.gnome.org/hughsie/2009/09/23/linux-is-about-choice/ [gnome.org]
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/ [gnome.org])
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.
Re: (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 the
Re: (Score:3, Informative)
The policy previously allowed users who were logged in to the local console to install signed packages from a repository. ... 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.
You are incorrect in equating local console logins with physical access. I pointed this out several times on the bugzilla, but it seems that the myth persists.
There exist OS-level tools such as x11vnc or x0rfbserver whose entire purpose is to provide remote users with the ability to manipulate the local console. These tools do not require root privileges to run. An attacker who gains remote access illicitly can compile or copy over an x11vnc binary and subvert the local console.
Of course, an attacker w
And the announcement got it wrong (Score:3, Informative)
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.
Re: (Score:2)
> This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.
Obviously wrong? How are they going to use sudo if it isn't configured by default. This is Fedora not Ubuntu
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: (Score:3, Informative)
With sudo, they don't need to type the root password, they need to type their own password.
Of course, you're still able to make the system behave so that users can install software without typing in their password -- it's just not the default now.
It would be nice, though, for package managers to support user installation (to the user's home directory).
Tempest in a teapot (Score:2)
How many Fedora installations actually have "users" and "admins?" The line that you don't want your users installing software just doesn't hold any water. Honestly if you have an "admin" and "users" you'll be wanting to harden the install anyway, and more than likely you will not want to use Fedora. Instead you'd do CentOS 5 or Ubuntu LTS. Most installs of Fedora are on single-user, home systems. Even in a family situation, a parent will likely want to enable parental controls anyway, so creating a lim
Re: (Score:2)
Even more ironically, most of the comments seem to indicate that sudo is a recommended solution! Are you kidding? ... If a user wants to do something that needs more privileges, you grant him carte blanche root access?
That's not what sudo does, necessarily. There is a file that can be used to list the commands that a given user/group can run using sudo. If the command you're running isn't in that list (including the arguments you're supplying) then you don't get permission to run it.
It's common to allow peo
Re: (Score:2)
Re: (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)