Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Red Hat Software Security Unix Linux

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."
This discussion has been archived. No new comments can be posted.

Fedora 12 Package Installation Policy Tightened

Comments Filter:
  • by jedidiah ( 1196 ) on Friday November 20, 2009 @10:27AM (#30170724) Homepage

    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.

  • Re:That was close... (Score:3, Informative)

    by juhaz ( 110830 ) on Friday November 20, 2009 @10:31AM (#30170780) Homepage

    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.

  • by Anonymous Coward on Friday November 20, 2009 @10:35AM (#30170826)

    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]).:

    Every time somebody writes "Linux is about choice" something inside of me dies. Just because something can be done, doesn’t mean it should be done.

    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:

    And so, long story short, we decided to revert the change for F12.

    Part of being an open source maintainer (and also my job at Red Hat) is to ignore trolls, but some of the messages I was getting yesterday were just personal attacks and abuse. That’s not cricket at all.

    (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:

    • "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. " (btw, the two "spins" don't actually exist. --ed)
    • "There's nothing to discuss here."
    • "You either trust the Fedora repos or you don't."
    • "I don't particularly care how UNIX has always worked."
    • "You missed the "in my opinion" line in your reply."
    • "There are other, *easier*, ways of rooting the system. "

    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.

  • by Antique Geekmeister ( 740220 ) on Friday November 20, 2009 @10:50AM (#30171008)

    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:Non-controversial (Score:3, Informative)

    by Antique Geekmeister ( 740220 ) on Friday November 20, 2009 @10:58AM (#30171108)

    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.

  • by blueg3 ( 192743 ) on Friday November 20, 2009 @12:17PM (#30172142)

    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).

  • Re:That was close... (Score:3, Informative)

    by AdamWill ( 604569 ) on Friday November 20, 2009 @12:35PM (#30172456) Homepage

    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.

  • by David Jao ( 2759 ) <djao@dominia.org> on Friday November 20, 2009 @03:48PM (#30175930) Homepage

    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 who has remote access is already very bad news for you, but that doesn't mean they have root, and it's no excuse for making it any easier for them to gain root.

    What boggles my mind is that Richard Hughes was apparently aware of the existence of tools like x11vnc and their effects, and yet he advocated in favor of this change anyway. I don't want anybody with this attitude to be even in the same room as any discussion on security policy. This is not a personal attack on Richard Hughes, it's just a simple fact. Security engineering requires a certain mindset, and if you don't have that mindset, then get out of the discussion.

One man's constant is another man's variable. -- A.J. Perlis

Working...