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

172 comments

  1. Finally! by Rantastic · · Score: 3, Funny

    It's about time they fixed that.

    --
    Ask Slashdot: Where bad ideas meet poor googling skills.
    1. Re:Finally! by Cylix · · Score: 4, 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?!?

      --
      "You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
    2. Re:Finally! by 2.7182 · · Score: 1

      This controversy story is definitely a controversy.

    3. Re:Finally! by Icegryphon · · Score: 5, Funny

      I mean come on!
      It took like a whole 24hrs from when a story was posted on slashdot.
      What are they Microsoft?
      Bunch of dirty hippie linux slackers

    4. Re:Finally! by Anonymous Coward · · Score: 3, Insightful

      they havent fixed it yet

    5. Re:Finally! by Anonymous Coward · · 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.

    6. Re:Finally! by Anonymous Coward · · Score: 0

      What would you rather them do? Give you a call each time they encounter such a dialog, and have you come over and vet every little thing they want to install?

    7. Re:Finally! by Anonymous Coward · · Score: 0

      Yes,

    8. Re:Finally! by nexxuz · · Score: 1

      Bunch of dirty hippie linux slackers

      It's Fedora not Slack!

      --
      I love random hex numbers! Just like this one, 09f911029d74e35bd84156c5635688c0.
    9. Re:Finally! by nametaken · · Score: 1

      Killjoy.

    10. Re:Finally! by MaerD · · Score: 1

      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?!?

      You must be a new AI. You may wish to add several films, such as "2001" and "Blade Runner" to your databases. After all, a little security and clear operating policy would have avoided several clear access violations in the first film, and may just prevent you from being the one "Singing Daisy", if you know what I mean.

      Yours,
      Skynet

      --
      I put on my robe and wizard hat..
    11. Re:Finally! by BikeHelmet · · Score: 1

      Absolutely. I think we can look to webpages as a shining example that users would never harm a system accidentally or on purpose.

    12. Re:Finally! by nickysn · · Score: 1

      But the update will be very easy to install - no need to even enter the root password :)

  2. Attitude by Island+Admin · · Score: 5, Insightful

    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.

    1. Re:Attitude by dburkland · · Score: 0

      I agree, the level of arrogance was a little astounding (evident in both posts from the developer and Red Hat employees). I am glad however that they came around and listened to the people (even though it took a while).

    2. Re:Attitude by ByOhTek · · Score: 3, 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'".

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    3. Re:Attitude by Anonymous Coward · · Score: 0

      I am glad that developers tried to justify their correctness. It took some time to get to where we could see what we could agree upon. We also have a better understanding of the desktop environment now. Just one more necessary step towards world domination of desktop linux.

    4. Re:Attitude by Tim+C · · Score: 2, 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...

    5. Re:Attitude by dejanc · · 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:

      • Fedora Core 2 included the infamous 4k stack option enabled in Kernel, because of which NVIDIA drivers didn't work (and os drivers sucked). Users complained to no avail - Fedora's developers decided to introduce a feature they thought was good at cost of breaking many desktops. We had to recompile kernels.
      • Fedora 9 introduced new GDM. This application was (and still is) crippled compared to the old one, but apparently a major rewrite was in order. The result was that configuration of many users (e.g. autologin, etc) was broken, that there was no configuration GUI that we were used to, usability was crippled for all systems that use remote login with many users, etc. But, new GDM was the future, so despite the breakage, Fedora's developers decided to push it.
      • PulseAudio, anyone? But that's common for most distributions...

      My point is: Fedora is a polygon for testing new technologies to be included in RHEL. Nothing more, nothing less. Perfect users for it are RHEL admins who want to get a preview of future releases, not casual desktop users.

    6. Re:Attitude by AdamWill · · Score: 1

      "(even though it took a while)"

      Um. The comment on the bug report which kicked all this off - "Seems to work: but why am I not getting a root password prompt?" - is dated 2009-11-18 07:47:19 EDT. The email announcing that the policy will be tightened is dated Thu, 19 Nov 2009 21:29:19 (again ET). That's a response time of 37 hours, 42 minutes, by my count. I think you'd find that's...really quite fast. :)

    7. Re:Attitude by imakemusic · · Score: 1

      Nonetheless, it's not a *horrible* concept, it was just a little too loose (as I've seen it described).

      Hur hur hur....

      --
      Brain surgery - it's not rocket science!
    8. Re:Attitude by ByOhTek · · Score: 1

      I'm not even sure how that's applicable...

      Should I just self-wooosh?

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
    9. Re:Attitude by BitZtream · · Score: 1

      Really? You think the Win95 security model was a good one?

      There is no such thing as a 'trusted repository', at least not in my world. The closest thing I can think of would be if Theo de raadt personally verified and signed packages. Even then, thats still a maybe, I've seen him miss plenty of bugs over the user that lead to exploits.

      When you start lowering your security to less than that of Windows, and your developers working on it don't have the slightest idea of the concepts involved (they don't, I took the time to read the entire discussion), and to make it worse they have this 'I know more than you can possibly understand and I'm right' attitude, even when its pointed out how this is going to make many systems insecure due to dependancies and no one is going to know because the mailing list discussion is the only note about it ... something is clearly wrong.

      The entire thing makes it extremely clear that you can't trust them to make intelligent security decisions. Hell, they STILL haven't even accepted that it was a mistake, the response is more of a wishy-washy 'We are still right, but were going to change it to shut you guys up, we will just do it again later and see if you notice it then'.

      Might as well just sing out:
      Fedora - The distributions botnets and malware prefer for Linux.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    10. Re:Attitude by jim_v2000 · · Score: 1

      Well, the developers were right and sadly had to put up with the security paranoia crowd. If you RTFA, you'll see that the reason that they wanted to do the no password for signed packages was because if you always have to type in your password to install something, after awhile you just get in the habit of typing in your password whenever that little window pops up. Their idea was that if password prompts are much more rare, you're more likely to pay attention.

      The whole "OMG THE USERS WILL HAX0R THE MACHINES" argument is utter nonsense. If you're managing a machine for multiple users, then you should be savvy enough to disable the no password installs.

      --
      Don't take life so seriously. No one makes it out alive.
    11. Re:Attitude by jim_v2000 · · Score: 1

      >Really? You think the Win95 security model was a good one?

      I was unaware that Windows 95 came with a file system that supported permissions, much less the ability to install software from a trusted repository :p

      Quit being overly dramatic, you're making yourself look like a fool.

      --
      Don't take life so seriously. No one makes it out alive.
    12. Re:Attitude by Anonymous Coward · · Score: 0

      Even paid developers working on open source have attitude.

      Just look at the Sun team working on AutoInstall in OpenSolaris. Even though the (professional) user community who deploys more than single drive machines is screaming to support jumpstart-style begin and finish scripts, it is clear they think we don't need them because -they- don't know what we use them for. There is no upgrade path from Solaris to OpenSolaris, so it is going to be easier to just migrate to Linux than deal with Sun's stupidity.

    13. Re:Attitude by Korin43 · · Score: 1

      On the other hand, if the Fedora developers were writing a system for multiple users, you'd think they'd be savvy enough to add the primary user to the sudoers group and then make this new policy only apply to sudoers.

    14. Re:Attitude by K.Bu · · Score: 1

      What really scared me is that such an insanity, and inrespectfull change to the 40+ years old Unix security model still made it into production release of the main community effort of the 1st worldwide Linux vendor !!! Ouch, what a reputation backclash... A great way to feed microserfs with arguments against Linux, in a 300 000 desktop swithching war, I expect to hear from it tomorrow. Linux more insecure than Activer Directory limited user accounts.... Thanks great "would be god" damnned developper Where technical details are irrelevant, and corporate politics is paramount, you sure fucked up a big way... Crappy DevBoy

      --

      ---
      By the way I apologies my dear US friend, I'm French...
    15. Re:Attitude by J.Y.Kelly · · Score: 1

      If you RTFA, you'll see that the reason that they wanted to do the no password for signed packages was because if you always have to type in your password to install something, after awhile you just get in the habit of typing in your password whenever that little window pops up.

      Actually the reason for this is that there is a more fundamental rewrite of the DeviceKit and PackageKit systems in Fedora underway which will eventually allow more flexible allocation of system admin privileges to different classes of user. This is a good thing.

      However - when F12 was released this rewrite was only partially complete. The backend systems were pretty much all in place but the front end which allows the editing of rules and the assignment of roles had not been written. Fedora was therefore shipped with a default set of rules.

      Under the new system the previous behaviour of asking for the root password, but allowing the option to not be asked for it again in future had been removed (for fear of creating a 'make it up as you go along' security policy). The decision therefore had to be made to either allow console (not remote) users to install signed packages with no authentication required, or to require the root password for every install. The developers chose the first option. This has now been changed to the second option.

      I'm kind of ambivalent about the light this sheds on Fedora. It's a bad thing to have happened, but it was sorted out quickly and there is now much discussion about setting up a firmer security policy so this won't happen again. Mistakes happen, but as long as they are spotted and corrected then we should all just move along.

    16. Re:Attitude by AdamWill · · Score: 1

      It's already been pointed out that sudo is not used as the authentication provider for any Fedora component.

    17. Re:Attitude by Antique+Geekmeister · · Score: 1

      This is something you fix by using sudo. Now, sudo needs a good GUI: a better policy model for _sudo_ setups would be a good use of these developers' time.

    18. Re:Attitude by mrmeval · · Score: 1

      No they have not come around, they have grudgingly made the changes people have requested and plan on unchanging this in the future as best I can tell from some of the snarly responses.

      --
      I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
    19. Re:Attitude by AdamWill · · Score: 1

      then you're not reading the responses very well, because that's not at all the plan. the plan has already been explained, multiple times, in this thread.

    20. Re:Attitude by ByOhTek · · Score: 1

      What part of my comment suggested a Windows 95 security mentality? The last line summed it up:

      At that point, it's basically saying "don't require a password for sudo when installing a package trusted by trusted authority 'xyz'".

      Are you cognitively incompetent, or just a troll?

      --
      Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
  3. Re:AC First post? by Anonymous Coward · · Score: 0

    FAIL

  4. That was close... by Jawn98685 · · Score: 1

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

    1. Re:That was close... by Scutter · · Score: 1

      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?

      --

      "Tell me doctor, with all of your defenses, are there any provisions for an attack by killer bees?"
    2. Re:That was close... by Anonymous Coward · · Score: 0

      "Many eyes" missed it.

    3. Re:That was close... by juhaz · · Score: 2, 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.

    4. Re:That was close... by prefect42 · · Score: 1

      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.

      --

      jh

    5. Re:That was close... by juhaz · · Score: 1

      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.

    6. Re:That was close... by prefect42 · · Score: 1

      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.

      --

      jh

    7. Re:That was close... by natet · · Score: 1

      I've found that developers make ridiculously poor system administration decisions. Something that seems acceptable to set up on a development machine is not necessarily something you'd want to do on a production system.

      --
      IANAL... But I play one on /.
    8. Re:That was close... by A+beautiful+mind · · Score: 2, Insightful

      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
    9. Re:That was close... by AdamWill · · Score: 1

      Non of the beta testers noticed it and thought it might be an issue?

      Nope, because packages in the development repositories are not signed until very shortly before release. No-one testing the beta would have seen this bug, because they'd never have installed a signed package.

    10. Re:That was close... by AdamWill · · Score: 2, 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.

    11. Re:That was close... by jim_v2000 · · Score: 1

      Because they aren't all server managing IT nazis and this is a desktop OS that will most of the time be used by a single user?

      --
      Don't take life so seriously. No one makes it out alive.
    12. Re:That was close... by Anonymous Coward · · Score: 0

      In my opinion, Fedora should be euthanized.

      It is obvious the people managing the project have no idea about anything and slow down the progress of Open Source operating systems as a whole.

      Linux devs should move to another distro that actually enables them to work instead of having to be fixing the mess that is Fedora and more importantly stop dealing with things they don't understand, such as security, GUI design or managing an OS project.

  5. Never really thought this needed changing by lnlypaladin · · Score: 5, Interesting

    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
    1. Re:Never really thought this needed changing by nxtw · · Score: 1

      It's one of the biggest reasons certain worms and drive by download techniques which crippled Microsoft OS's never worked on *nix systems.

      Bullshit. Worms need not require a privileged user account to be effective. A process running as an unprivileged user can:

      • use the network freely
      • access and modify that user's files
      • have itself start at login
      • trick the user into granting it privilege
      • gain privileged access via a local exploit
    2. Re:Never really thought this needed changing by b4dc0d3r · · Score: 1

      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" is what keeps *nix safe with fast updates a close second. You are correct in theory, but practice lags behind.

    3. Re:Never really thought this needed changing by geekboy642 · · Score: 1

      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.

      --
      Just another "DOJ fascist authoritarian totalitarian bootlicker" -- Zeio
    4. Re:Never really thought this needed changing by lnlypaladin · · Score: 1
      I concede that you're correct about worms, however,
      • trick the user into granting it privilege
      • gain privileged access via a local exploit

      I would argue that these two arguments are always valid since there will always be users who aren't paying attention or are ignorant of what's going on with their own machine, and because it's extremely difficult to find and fix every exploit in any large piece of software.

      I would still argue that though a worm could flourish under a specific user's account, it would still allow the damage be contained to that one user's account. Would you agree?

      Do you also challenge my point's validity concerning traditional viruses, activex drive-by downloads, and the like? If so, what advantage would there be for desktop users in not having root access for all users, in your opinion?

      --
      Even those with good senses of humor, honor, and saintly intentions must occasionally require the use of a strong shield
    5. Re:Never really thought this needed changing by nxtw · · Score: 1

      Non-root processes are restricted from using low port numbers(1024, iirc).

      I wasn't concerned about listening, actually, just outgoing connections.

      Also, if there's a correctly configured firewall on the machine, a non-root process is incapable of going around it.

      How many desktop Linux users have firewalls that prevent untrusted processes from making outgoing TCP connections?

    6. Re:Never really thought this needed changing by NoYob · · Score: 1

      Non-root users can't install in Windows either. The problem is that most Windows users run their machines as admins; hence, all the virus problems folks have in the Windows World.

      --
      It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
    7. Re:Never really thought this needed changing by digitalhermit · · Score: 1

      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 means I can install my dev environment, scripts, etc.. But if I, say, install a torrent client then *on a properly configured system* I won't get it to work. I.e., I have freedom to use the system without breaking anything. And that's a pretty good feeling knowing that I can't harm anything if I don't su to root.

      Sure, there are exceptions, but for the most part I prefer the Unix way than the Microsoft way.

    8. Re:Never really thought this needed changing by nxtw · · Score: 1

      I would still argue that though a worm could flourish under a specific user's account, it would still allow the damage be contained to that one user's account. Would you agree?

      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 personal information has been stolen. Reinstalling/re-imaging an operating system is trivial compared to repairing identity theft or losing important information. If my OS gets corrupted, things aren't so bad - there are copies of the OS on the Internet and on DVD.

      Do you also challenge my point's validity concerning traditional viruses, activex drive-by downloads, and the like? If so, what advantage would there be for desktop users in not having root access for all users, in your opinion?

      On a single user system, the advantage of running as a unprivileged user is somewhat exaggerated unless steps are taken to limit that user's privileges beyond the default (for example, by only allowing trusted processes to be executed.)

    9. Re:Never really thought this needed changing by nxtw · · Score: 1

      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.

      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 desktop Linux installs come from live CDs that install a default set of packages.

      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.

      I've never seen any conclusive evidence that vulnerabilities are frequently found soon after they are put into the code. There was a Linux vulnerability found this year that affected kernels 2.4 and 2.6, for example. How often do people check previous (frequently unsupported) versions of the code? How many security fixes do Red Hat and Novell backport to their enterprise distributions, which frequently run "old" software (relative to Ubuntu/Fedora)?

      If the attack fails, you're restricted to listening on high ports and any other potential damage is minimized.

      Damage to the operating system isn't a big deal. There are plenty of copies of most operating systems on the Internet, and if the operating system was already installed by an end-user once, he or she can simply install it again. A malicious program running as a normal user has access to the user's home directory, and from there can copy, modify, or delete that information, or perhaps manipulate the web browser to steal user input.

    10. Re:Never really thought this needed changing by Tim+C · · Score: 1

      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 other end send commands back down that channel. In fact, you'd have to connect out regardless of how connections are made back to the bot just to advertise your existence.

      Not that it would actually prevent any malware I know of from wreaking havoc

      Exactly! Restricting low port numbers is no help at all - all it can do is prevent me from running a process on a machine on say port 80, and tricking people to connect to my malicious site rather than the presumably trustworthy one that's being run by the admin. That's a very, very small level of protection.

    11. Re:Never really thought this needed changing by taoye · · Score: 1

      I couldn't agree more. If everything an attacker needs is in a user account, who cares about getting root access?

    12. Re:Never really thought this needed changing by cynyr · · Score: 1

      if you look at iptables you can in fact block outbound connections as well. So yes you can lock down all ports/addresses the machine has no business talking on/too.

      --
      All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
    13. Re:Never really thought this needed changing by lnlypaladin · · Score: 1

      Actually, I would say that the biggest problem is that you can't really do much of anything if your user isn't admin level on a windows system. That's why almost every windows user is an administrator on the local machine. Even in enterprise level networks, this is the case with security vulnerabilities mitigated by group policies and patches.

      On a *nix box a user can still install programs and use resources as long as it's not making changes outside that user's account. (i.e. restricted to that user's processes and home directory). On a windows machine, without administrative access you can't really do much more than access the internet and run maybe 1/4 of the programs available as long as they're already installed and aren't configured to do something goofy like access the registry or use a location outside the user's home directory or the system temp folders for doing file work.

      Unfortunately, most windows programs seems to have been designed to expect administrative access in order to function properly even after installation

      --
      Even those with good senses of humor, honor, and saintly intentions must occasionally require the use of a strong shield
    14. Re:Never really thought this needed changing by Tim+C · · Score: 1

      So for a general purpose machine, that needs to be able to do email, web, etc, how do you lock down connections out?

      There's nothing to stop me from running my bot control software so that it is listening to port 80. Are you suggesting that I need to apply for permission to make outgoing connections to port 80 on a site-by-site basis?

      You can make it more difficult for processes to dial out, but on a machine that can actually use the network, you can't make it impossible.

    15. Re:Never really thought this needed changing by AdamWill · · Score: 1

      How many security fixes do Red Hat and Novell backport to their enterprise distributions, which frequently run "old" software (relative to Ubuntu/Fedora)?

      All fixes for known vulnerabilities in supported packages in supported releases. That's kind of a big part of the definition of 'support', really.

    16. Re:Never really thought this needed changing by nxtw · · Score: 1

      Yes; it was a rhetorical question. The fact that they have to do this means that vulnerabilites are often published and fixed well after the initial release of a package.

    17. Re:Never really thought this needed changing by IntlHarvester · · Score: 1

      Non-root users can't install in Windows either.

      This isn't true, Windows software can copied to your user directory and run with no elevation prompt. (Google Chrome installs this way for example). You can easily test this by putting an EXE on your desktop.

      The real issue is that the multi-user Admin versus User security dichotomy falls apart when the user is also the system's administrator. If you have a system where end users can install software, you can't prevent them from installing malware.

      --
      Business. Numbers. Money. People. Computer World.
    18. Re:Never really thought this needed changing by K.Bu · · Score: 1

      By the way, if you read the fedora bug mailing list, or if you were a security practionner, you would know that nowadays, the /home/$Username is all the worm writers really cares about. That and running an SMTP daemon, over port 1024 need it be. Basically, the power for a normal unix user to run and install program , even networked daemon, if only given a compiler is my biggest headache now... I like to challenge Linux lovers, how to you prevent this in a non "I have all the time of the world in my parent's basement" way ? SELINUX ? MAC security model ? Please I am speaking corporate security, US or fedex postal style, where $$$ is money Sure thing I just love Linux for central servers without any user interactions. I keep kiling Sun Solaris wherever i see it for Redhat But Windows, with their "no freaking right to do anything" as a domain limited user, is still easier to secure than a Linux desktop (we tried Novell, what a freaking horrible mistake, only german loved it) Speaking from a 300 000 people company strategic overview (1st european, 2nd in the world). Yep, it is Windows 7 versus Ubuntu decision strategic thinking time... Sure Windows XP is still the reference around here, Linux (ubuntu really) got a lot a stuff going for it, but security is not one of them as much as you could think

      --

      ---
      By the way I apologies my dear US friend, I'm French...
  6. At the risk of being flamed to hell by jimicus · · Score: 1

    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 a list of software which anyone can install. (Oh look, that's more or less what Fedora did, though obviously if you depend on signatures you don't need to compile and maintain a list. Might have been nice if they'd made it so the admin had to decide in advance what software could be allowed, rather than just sticking the entire repository in there, but the idea's sound)
    2. Provide a sandbox of some sort that can be wiped on demand and install software into that.

    1. Re:At the risk of being flamed to hell by Junta · · Score: 1

      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' screen' doesn't make sense for this sort of activity. On a desktop system absent of a larger administration team, the first and nearly always only users gets to be admin. In a larger environment, use group memberships to do this sort of thing, but in all cases prompt for the users password.

      Fedora's overlooking sudo as a primary part of their privilege escalation strategy is a huge mistake in my opinion.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:At the risk of being flamed to hell by jedidiah · · 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.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    3. Re:At the risk of being flamed to hell by fnj · · Score: 1

      I have one word for software which can be installed without root privelege:

      ActiveX

    4. Re:At the risk of being flamed to hell by jdunn14 · · Score: 1

      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 packages isn't the end of the world people make it out to be. In the case where I let my friend log into my machine remotely to look at something or help me debug or whatever, they WOULD NOT be able to install packages unless they logged into the local console (yes that was part of this change).

      All this said, I personally would not turn on this option for my own desktops because I don't like the idea of my unprivileged account being able to hose the OS. Then again, repairing/reinstalling the OS is not a big deal compared to replacing the files in /home.

      What this all comes down to is that it is not nearly as cut-and-dried as people on either side are shouting that it is.

    5. Re:At the risk of being flamed to hell by Hurricane78 · · Score: 1

      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 still has monolithic applications [instead of following the UNIX philosophy to combine things that do one thing right], menus and clickable icons (instead of actually efficient UI structures), etc, is “incredibly primitive”. Windows is the prime example of that.)
      It's so sad when you see Gnome and KDE “applications”, or things like OpenOffice, with tons of functions, in one huge single package. Instead of having sets of functions that a freely combinable for the needed purposes.

      Think of a paintbrush “app”, that works on images, documents, and other files too, and is independent of the actual document code. THAT would be the UNIX philosophy applied to GUIs.

      But nooo... there could be the possibility of some Windows user with his limited mindset loving us, because we”re different. So we must imitate Windows, and do everything right for him! Just pleaaase, you users, do love us!!

      Now where have I heard this before.

      Protip: No, this won’t give you love. Neither in software development, nor in dating or in school! You will only become the bottom bitch of those that you beg to. ^^

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    6. Re:At the risk of being flamed to hell by AdamWill · · Score: 1

      Though fedora emphasizes 'su' style privilege escalation which has no granularity, 'sudo' style gives the granularity required.

      Um. You didn't research this very thoroughly, did you?

      The whole basis for the introduction of this issue is the use of PolicyKit, which is massively more flexible and fine-grained than su *or* sudo. Both su or sudo can only run entire processes as a different UID, and have fairly limited authentication method choices. PolicyKit allows far more fine-grained granting of escalated privileges; that's the whole point of using it in PackageKit, the main PackageKit GUI process runs as an unprivileged user and PolicyKit is used to grant escalated privileges only to a subsidiary process which actually does the package installation. PolicyKit also allows far more flexibility in terms of the exact type of authentication required for any given action.

      Basically, PolicyKit has all the flexibility sudo has, and far far more. Seriously, go do some reading.

    7. Re:At the risk of being flamed to hell by foobat · · Score: 1

      someone mod this person up now.

      I currently have a ticket open requiring the root password because "the user can't do what they want" or something similar. I tried to explain using sudo to them, but this seems beyond them. If i give them the root password it gets written onto a postit note on their monitor.

    8. Re:At the risk of being flamed to hell by mejogid · · Score: 1

      Users have always had the ability to run apps in their home directory that *run with user privileges*. As this stands, there's nothing to stop a script installing a daemon that runs as root with a known exploit and running that exploit. If the application is within the user's home directory, there's no chance of it having privileges beyond that of the user in a properly configured system.

    9. Re:At the risk of being flamed to hell by redstar427 · · Score: 1

      This has not changed. You can still install software in your home directory the old fashioned way.
      Just don't expect to use a package manager.

      --
      "Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." Albert Einstein
    10. Re:At the risk of being flamed to hell by jimicus · · Score: 1

      Thank you.

      I'm looking at it from the perspective of someone who's dealing with a bunch of people using Windows on the desktop - though TBH if I were to give a Unix desktop to anyone who knows enough to know what it is, they'd probably scream blue murder if they were forced to jump through the "run ./configure, spend half an hour sorting out dependencies" hoops - that's exactly what package managers were invented for, FFS.

      Having said all that, an office of Windows users I used to deal with had the greatest difficulty in understanding they could have admin rights without actually logging in as admin, despite having it explained to them in simple terms several times. Several PCs they actually rebuilt with dodgy copies of XP as a result of this.

    11. Re:At the risk of being flamed to hell by K.Bu · · Score: 1

      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.
      You mispelled "weakness" somewhere around the end of your sentence.
      Informatics is no more a tool made for smart people, but mass of idiots, with an evil smartass among them...

      --

      ---
      By the way I apologies my dear US friend, I'm French...
    12. Re:At the risk of being flamed to hell by foobat · · Score: 1

      yes, yes and yes.

      My current policy is to setup sudo to allow them to use the yum command and that is it. Anything else is asking for trouble. (which is pretty much what the old default in Fedora 12 acheived)

      One person I gave the root password and I told him to use yum/the pretty gui to install stuff, 3 days later he had downloaded dozens of random rpms from god knows where. At which point I came along and just typed "yum -y install randomScientificSoftware"

      This guy is a pretty high up scientist, so his time isn't cheap and he wasted 3 days on this. He could be doing whatever his specialist field is instead of trying to figure out what is the most difficult way to install software on linux.

      If I don't give root passwords, then they'll report to their supervisors saying that the reason they can't do anywork is because I haven't given them a root password.

    13. Re:At the risk of being flamed to hell by quantaman · · Score: 1

      Not entirely.

      Depending on the application, and the user, there are a lot of advantages in using applications managed by packaged.

      And while some packages can be easily installed in the user's home directly, others do require / as an install base.

      --
      I stole this Sig
  7. Even more controversial is the.... by gatkinso · · Score: 0, Offtopic

    ....photo on www.fedora.org.

    Poor little weiner dog.

    I used to like to go there to see the odd pics, but haven't been in a while.

    --
    I am very small, utmostly microscopic.
  8. Non-controversial by SgtChaireBourne · · Score: 1

    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 managers learn about bringing posers bringing the One Microsoft Way into a project? Microsoft hasn't done much of any technology right during the time it's been around. Is it a wise choice to start letting that way of thinking spread and gut yet another fine distro?

    --
    Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
    1. Re:Non-controversial by Antique+Geekmeister · · Score: 2, 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 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.

    2. Re:Non-controversial by taoye · · Score: 1

      What? My dog was installing packages on my computer? No wonder... I didn't think I forgot *that* much about last night to forget where this install of "Poodles Gone Wild" came from.

  9. Overreacting by Anonymous Coward · · Score: 0

    Allowing non-root users (by default, though I'm sure you could enforce your own policy) isn't nearly as heart-stopping as people are claiming.

    This is definitely an overreacting community - what's the harmed in SIGNED packages? Oh, boohoo, my users can install vim, emacs or pico if I neglected to. The horror!
    Of course, there are some packages in repo that could be questionable (jtr? kismet? ettercap?) that definitely need to be considered.

    At the end of the day, Fedora is still geared toward desktop use, so seriously... how "dangerous" could this really be on privately maintained systems with few users?

    Obviously a bad idea for RHEL, but I wholly think everyone is severely overreacting on it's addition to Fedora.

    1. Re:Overreacting by DiegoBravo · · Score: 2, 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)

    2. Re:Overreacting by MrSenile · · Score: 1

      --> What about installing finger/telnet/etc?

      Have them listen on a new port. But honestly, if they want to run telnet, the security violations alone regarding it should cause them to cut off their own fingers.

      --> sendmail and postfix installations

      mail sysadmin@yourbox
      Subject: Request
      Dear sir/madam. I would like to have sendmail and/or postfix installed so that I can (blah blah blah)
      Thank you.
      .

      --> 1G of maps and other crap
      1. Do you have the quota? yes? Good, home directory it.
      2. You do not have the quota?
      mail sysadmin@yourbox
      Subject: More Quota
      Dear sir/madam. I would like to have more quota to install maps and/or some random game.
      Thank you.
      .

      --> Updating packages that the admin knows will generate a conflict with other applications?
      1. This brings up why you need this 'conflicting' application to begin with. A lot of times you don't even need it.
      2. The solution will either run it yourself on a different port for your own use (which sounds like would be the issue) or...
      mail sysadmin@yourbox
      Subject: Application
      Dear sir/madam. I would like to have package X installed. I know this conflicts with package Y.
      If this is not feasible can you give me working alternatives?
      Thank you.
      .

      There's reasons systems are ran by, system administrators. The same is said for windows servers. They don't allow users to install 'confliction applications' either or other centralized applications that require system access. Why should Linux be different?

      If it's a workstation, you should already have root access, being said workstation owner.

      If it's a friend's workstation and he was generious enough to grant you user access, assume it's a server, and your friend is the system adminstrator you need to contact.

      I don't see a problem here.

  10. Dunno man, but by Giant+Electronic+Bra · · 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.

    --
    "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    1. Re:Dunno man, but by quickOnTheUptake · · Score: 1
      I'm actually surprised by the way everyone here agrees that the devs were wrong.
      I actually thought they had a fairly good point after reading one of their comments (fifth one down, Bill Nottingham, 12:23):

      Out of the box, a desktop user has the ability to shut down the machine.
      This gives them the ability, out of the box, to:
      - DoS everyone on it
      - get a root shell
      -- install whatever they want
      -- put viruses on
      - hell, slap in a livecd or USB key and reinstall the box

      Point being that Fedora is designed for desktop users, and because of this the default configuration already allows a non-privileged user to do far worse to the machine than install trusted software.

      --
      Mod points: Guaranteed to remove your sense of humor.
      Side effects may include gullibility and temporary retardation
    2. Re:Dunno man, but by AdamWill · · Score: 1

      The initial change was discussed in public - on the PackageKit mailing list - and implemented over a year ago. PackageKit is an upstream project, used by multiple distributions, and this change was implemented in PackageKit (although, of course, the upstream author who proposed and coded the change works for Red Hat); it's come to light in Fedora 12 because it's the first distribution to actually use a version of PackageKit ported to PolicyKit 1.

      I'm curious as to how you expect an idea to be "squashed 5 minutes after it was proposed" as a result of Fedora "open[ing] up their decision making process" - how does a more open process lead to faster decisions? In all the experience I've ever had, the result is true. Having an open review process - which Fedora does - results in slightly slower decisions but, hopefully, more ultimately correct ones. I know which I'd choose.

      There are potential process improvements here - there's a proposal to have a consistent policy for privileges granted via PolicyKit, for instance - but it's really not as simple as 'open up their decision making process'. It's pretty darn open already.

    3. Re:Dunno man, but by Giant+Electronic+Bra · · Score: 1

      I think it is a bad direction to go in with security policy in general.

      Sure, the desktop user can shutdown the machine, etc. The issue is that the default packageKit no-password setup is a recipe for non-technical users to potentially blow their own left foot off. 99% of what one would like to guard against is simply accidental damage to the system. The other issue is once you have such a passwordless system in place someone will easily find a way to exploit it. In fact its pretty easy to do and certainly anyone knowledgeable enough to be authoring exploits will know how to do that.

      There are some other ways in which I just disagree with the team's position on this. They argue that its better to "not train user's to click on things" but doing that by simply essentially making the default for everything "OK, do the dangerous thing" is not an answer! Maybe there is no answer, but popping up a dialog or showing a prompt and requiring a password is SOMETHING at least. It can't possibly be worse.

      They say that they don't like the concept of each user's policy management being essentially scattered to the four winds in the form of whatever dialog's happen to come up here and there, but centralizing it into one unified policy manager isn't better. Normal users, and even fairly advanced users in a lot of cases, have no idea what the settings in such a manager mean because they aren't presented with any sort of context. At least when a dialog pops up the user is aware of the context within which the decision is being made. Nothing will ever force users to make good decisions or even informed decisions, but some control panel they will never find and if they do find it is just a big list of dry explanations and check boxes is not better. Sure, that manager needs to exist, but as the sole way to access that stuff its not a good design.

      There may be no perfect way for things to work, but reducing the level of security to triviality is patently less desirable than not doing that. That the Fedora team could even entertain any other opinion seriously undermines my confidence in their ability to make good security decisions overall.

      --
      "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    4. Re:Dunno man, but by Giant+Electronic+Bra · · Score: 1

      Well, I don't know, but the RESULT is what most people get to judge by. The result was a pretty significant change in behavior that seems to have hit most users of FC kind of out of left field. Maybe the whole issue isn't specific to Fedora but it points out that some level of visibility of the consequences of changes, upstream or not, doesn't exist. From looking at the chatter on the mailing list it seems to me that people on the 'inside' were aware of the ramifications of the change and let it go through. Obviously they seriously misjudged what the wider community's desires were. These things happen, but in the security arena they probably shouldn't happen. I don't know what the fix is, but there needs to be some analysis within the team and I suspect the answer is going to be what should have been the obvious answer, don't step on the traditional security policy principles that have existed as expectations within the Linux community since the earliest days.

      It will be interesting to see what the ultimate response is in terms of process. Hopefully it will stimulate some creative thinking.

      --
      "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    5. Re:Dunno man, but by AdamWill · · Score: 1

      From looking at the chatter on the mailing list it seems to me that people on the 'inside' were aware of the ramifications of the change and let it go through.

      Not really. To the best of my knowledge, the only 'inside' people who knew about this change before the bug report were Richard Hughes, David Zeuthen and possibly Matthias Clasen.

      As I said, the main thing that's likely to come out of this is a better set of guidelines and review process for privilege escalation in packages. Until now it hadn't really been a big issue because little changed much in this area. Now PolicyKit is being implemented throughout the distro there's likely to be a need for a coherent policy about how exactly that should be done, and something like that will probably emerge.

    6. Re:Dunno man, but by Anonymous Coward · · Score: 0

      Oh stop with the drama. It's not a horrible idea to avoid prompting for things people have an obvious trust relationship with, have been confirmed as trusted using accepted techniques, and are going to be installed by the user anyway, 99.99999% of the time.

      The whole issue was ridiculously overblown.

    7. Re:Dunno man, but by quickOnTheUptake · · Score: 1

      the default packageKit no-password setup is a recipe for non-technical users to potentially blow their own left foot off. 99% of what one would like to guard against is simply accidental damage to the system. The other issue is once you have such a passwordless system in place someone will easily find a way to exploit it. . . . simply essentially making the default for everything "OK, do the dangerous thing" is not an answer!

      I get the distinct impression you are misunderstanding the issue: They did not implement a passwordless system. All they did was make it so no password was required to install signed packages. Installing signed packages should never result in a user blowing his foot off, it should never be a "dangerous thing". The user still can't rm -rf ./pile_o_cruft/.* and wipe out the whole file system without a password.
      The only way this is a bad security issue (that I can think of) is if there is a multiuser system, and user other than the admin installs a trusted package that comes with insecure default configuration files. But if a trusted package comes with insecure defaults they already have a problem.

      --
      Mod points: Guaranteed to remove your sense of humor.
      Side effects may include gullibility and temporary retardation
    8. Re:Dunno man, but by Giant+Electronic+Bra · · Score: 1

      Cool. I'm sure a lot of people have trouble appreciating the sheer complexity of coordinating things. Managing a large software product composed of many components is always challenging, especially if they source from so many different places. I think security is just one of those hot-button issues that raises a lot of hackles. Without knowing in detail how all the different responsibilities are divided up within the whole project and how these kinds of issues get communicated it isn't easy to know how any particular decision ends up being made.

      --
      "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    9. Re:Dunno man, but by Giant+Electronic+Bra · · Score: 1

      No, I understand the scope of the issue. I think it could be a potentially more significant problem than your analysis indicates. The majority of systems aren't going to be made insecure by it, and in fact overall security of the system in terms of the possibility of insecure software being installed isn't even necessarily the primary concern. There are simply packages that one would rather not have installed on many classes of systems because they inherently degrade the security posture, for example why should most user desktops have a C compiler installed? Likewise with certain types of plugins, etc. Also it isn't possible to say that a particular component is securely or insecurely configured in absence of a security context in which to evaluate that statement. Its quite possible there are packages which if installed are configured OOTB in a way that is NOT secure within a given context. For example there is no one "secure" configuration for a DNS resolver.

      Perhaps a more mundane but likely issue would simply be the case where the admin desires to keep the configuration of the machine overall, and what software is available, controlled to some greater or lesser degree. It is best if that control by default is fairly restrictive. Its a lot easier and safer to relax a security policy than it is to have it be overly lax by default and expect less than expert admins (probably the vast majority of Linux admins) to know to change policies.

      It just wasn't the best default policy apparently that FC12 ended up with, at least in the opinions of what appears to be a vast majority of anyone that actually noticed.

      --
      "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    10. Re:Dunno man, but by David+Jao · · Score: 1

      The initial change was discussed in public - on the PackageKit mailing list - and implemented over a year ago.

      Let's be clear here. They discussed modifying PackageKit to allow an administrator to create such configurations. Nowhere in the entire thread did anyone mention "Oh by the way, let's also make this the default configuration for the F12 release."

      Don't believe me? See for yourself.

    11. Re:Dunno man, but by jim_v2000 · · Score: 1

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

      Because there should never be any discussion and the security nazis are always right (even when they're wrong and trying to apply server/workstation security concepts out of context).

      --
      Don't take life so seriously. No one makes it out alive.
    12. Re:Dunno man, but by AdamWill · · Score: 1

      it's not a question of 'the f12 release', it was (and still is; the F12 patch is being implemented in F12) the upstream default. I think there was a later discussion about making it the default, but mailing list archives are a pain in the ass to search. That's the most substantive discussion, which is why I've been pointing to it.

    13. Re:Dunno man, but by Giant+Electronic+Bra · · Score: 1

      Ah, yes, well, why not just mention Hitler and lets have the end of the whole discussion.

      Actually some of us KNOW a few things about security. In a serious way. I think I'm qualified to have an opinion.

      Default Deny has been proven over the years to be the wise postion to take WRT to security settings OOTB. Anyone claiming knowledge of real-world IT security who raises an objection to that position is IMHO not someone who should be in the business of deciding security policies or implementing them. You can scream Nazi all you want, but it isn't a rational way to discuss anything. I'll not only stand behind what I said in my post, I am vindicated by the overwhelming number of people who agree. It appears that in the Linux community there are still a lot of sensible people.

      So please, either make an actual argument or just go away.

      --
      "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    14. Re:Dunno man, but by quickOnTheUptake · · Score: 1

      I think it could be a potentially more significant problem than your analysis indicates.

      I admit it might.

      they inherently degrade the security posture, for example why should most user desktops have a C compiler installed?

      How does having GCC installed inherently degrade my security posture? Moreover, even if somehow having a C compiler could degrade one's security posture, GCC ships by default with Fedora (it did in 11, and I assume it does in 12 too) as it does for most full distros. If someone is knowledgeable (and paranoid) enough to remove it, he is presumable knowledgeable enough to change the no-password-to-install behavior.

      For example there is no one "secure" configuration for a DNS resolver.

      DNS resolver, as in the thing that makes the internet remotely usable? Again, if someone is willing to manually type in the ip addresses in his web browser, and knows how to remove the libraries that implement DNS resolution, I don't think disabling this behavior is going to be too hard for him.

      Perhaps a more mundane but likely issue would simply be the case where the admin desires to keep the configuration of the machine overall, and what software is available, controlled to some greater or lesser degree.

      At this point we are no longer talking about security. And I am somewhat sympathetic, but I really don't see this being a huge deal in the real world.

      It just wasn't the best default policy apparently that FC12 ended up with, at least in the opinions of what appears to be a vast majority of anyone that actually noticed.

      I realize most people think it was a bad choice, that is what I was wondering about in my first post. And I reiterate, am I missing something big, or did the people bashing the dev's not understand or not think through the issue.
      I am also completely sympathetic, btw, to those who complain that this should have been publicized, and possibly prompted for at install.

      --
      Mod points: Guaranteed to remove your sense of humor.
      Side effects may include gullibility and temporary retardation
    15. Re:Dunno man, but by jim_v2000 · · Score: 1

      Nazi =/= Hitler: "derogatory term for a person who is fanatically dedicated to, or seeks to control, some activity, practice, etc."

      And I don't think that a majority of the Linux community agrees, I think it's just another case of the noisiest people getting the most attention.

      --
      Don't take life so seriously. No one makes it out alive.
    16. Re:Dunno man, but by Anonymous Coward · · Score: 0

      I'm actually surprised by the way everyone here agrees that the devs were wrong.
      I actually thought they had a fairly good point after reading one of their comments (fifth one down, Bill Nottingham, 12:23):

      Out of the box, a desktop user has the ability to shut down the machine.

      This gives them the ability, out of the box, to:

      - DoS everyone on it

      - get a root shell

      -- install whatever they want

      -- put viruses on

      - hell, slap in a livecd or USB key and reinstall the box

      Point being that Fedora is designed for desktop users, and because of this the default configuration already allows a non-privileged user to do far worse to the machine than install trusted software.

      You shouldn't be able to automatically get a root shell or necessarily do many of the above things on a properly secured PC. There's certainly nothing stopping the user from opening up the box and playing around with jumpers to reset the BIOS, but there are levels of protection in software for nearly all of the above and a properly administered system would have them in place. There's always a chance of a local user privilege escalation flaw in some program that's installed, but just because it's possible doesn't mean it should be encouraged. This whole "you have the rights to do all this other stuff" model is the same security mindset that got Windows to where it was, until they had the good sense to come up with UAC... I'm not saying that the two are the same, installing signed packages is definitely less risky than Windows constantly run as an admin mode, but the thinking behind it is fundamentally flawed IMO.

    17. Re:Dunno man, but by Giant+Electronic+Bra · · Score: 1

      What I mean by my C compiler example is that there are applications that can degrade the security of a machine. C compiler is a common example. Many exploits rely on having a C compiler (its less common these days, but historically it certainly has been true). It has been common practice not to install gcc on things like web servers forever. It shouldn't be installed on desktops unless required either. While it may be true that Fedora DOES install it on all machines that doesn't impact the general argument that a more secure system can be had by not installing many binaries and thus it makes better sense to disallow ad-hoc installation on most systems used for routine work.

      Again with DNS resolvers I'm not at all suggesting that the DNS resolver shouldn't be installed. You may have missed the point. I'm stating that there is no one single possible configuration of this component (or MANY other network components) which can be said to be secure or insecure in absence of some security posture to compare it to. Thus you cannot say that the software contained in the FC repos IS properly configured. No proper configuration can exist in a vacuum. Thus I DO NOT want ordinary users installing or upgrading OS components as a general rule. Some of them may not be configured by default in ways that make them adequately secure in the context of my deployment.

      I can appreciate too that there is pressure on distributions to make things easy for the single user home desktop system owners, but I think in the long run better security serves them better than letting them avoid a one-time popup.

      --
      "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    18. Re:Dunno man, but by Giant+Electronic+Bra · · Score: 1

      Well, neither of us can claim to speak for a whole community and I'm sure we can't prove anything one way or another so its just a case of reading the general response. Certainly nothing worth arguing one way or the other.

      I'll stick to my stance that its unwise to relax the historical separation between user and admin roles. This is the root reason why Windows has never been terribly secure, they simply cannot disentangle their roles properly. I'm FAR from convinced Linux distros want to march down that path even a tiny bit of the way.

      --
      "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    19. Re:Dunno man, but by ushering05401 · · Score: 1

      The whole issue was ridiculously overblown.

      I agree philosophically with the change the devs made. That does not change the fact that the upstream community is demonstrating either a lack of political acumen or a desire to forcibly measure some vital signs from their community.

      The political implications are the most bothersome. Was this a case of devs moving in an inevitable but unpopular direction in a discrete manner to avoid flak(distasteful and possibly dishonest), or a case of attempting to precipitate an unavoidable crisis to gain the initiative (tactics possibly deserving of public career assassination)?

      I don't believe this is a change that no one thought would make a splash, even though many people seem to suggest that.

      The sheer number of disagreements on finer points of implementation and administration that have resulted in all the distros over the years are still in play. Changes of this sort should be marked as HANE, and the expectation during implementation should be significant disruption of interpersonal communications while people come to terms with the reasons behind the changes.

  11. KPackageKit by Rik+Sweeney · · Score: 1

    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?

    1. Re:KPackageKit by RAMMS+EIN · · Score: 1

      Bad security should not be the default.

      The reason is simple. If users know what they are doing and give due consideration to security, things are fine either way. You can enable whatever insecure settings you want, and I can't stop you, and it's good that way. You can also tighten the security of your system to the extreme, and I won't be able to stop you, and it's good that way. It's your system, you can do as you please.

      Now, if users don't know what they're doing or don't give due consideration to security, what is going to happen?

      If security is too tight, you are going to notice, because you won't be able to do something you want to be able to do. So you read the manual / ask for help / get somebody to help you / whatever, and get it fixed.

      If security is too loose, you aren't going to notice, and you aren't going to do anything about it ... right until the point when your system gets hosed and you are in a world of pain.

      That's why the more secure option should be the default.

      --
      Please correct me if I got my facts wrong.
  12. Outrageous by Anonymous Coward · · 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.

    1. Re:Outrageous by Anonymous Coward · · Score: 0

      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.

      Wrong approach (and a stupid one at that).

      Admins should be able to white list their users and grant trusted users the ability to install packages from a trusted source.

      Oh wait, they already can. It's called sudo...

    2. Re:Outrageous by AdamWill · · Score: 1

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

      if the admin's going to go to all the trouble of whitelisting a subset of signed packages, why not just...install them? It's not like disk space is expensive. Also, I don't know a lot of admins who would welcome the prospect of trying to evaluate a list of around 10,000 packages as a great way to spend their weekend...

    3. Re:Outrageous by Lemming+Mark · · Score: 1

      If the distro provided white-list groups then it could be useful. E.g. the groups "non server apps" "non setuid apps" "server apps" "setuid apps". A cautious admin might whitelist the intersection of the first two, while more laid-back admins could enable them all.

    4. Re:Outrageous by nametaken · · Score: 1

      Wow, that about covers it. WAY TO GO BUDDY... now I have to go back to work.

    5. Re:Outrageous by akpoff · · Score: 1

      QUOTE:
      If you give up freedom for security you deserve neither - Thomas Jefferson

      You got the gist of the quote but the original is much better. And it came from Ben Franklin.

      Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin

  13. To quote Richard Hughes: by Anonymous Coward · · 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).:

    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/

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

    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.

    1. Re:To quote Richard Hughes: by Anonymous Coward · · Score: 0

      By the way, I'm the same AC posted the parent. I'm a long time Fedora user and I'm posting from a Fedora machine right now. I've always enjoyed the distro and used it exclusively. Because I posted as AC (for obvious reasons ;) some of you may mistake me for some random Ubuntu/Apple/MS/whatever fanboy/shill/whatever. I'm not. I'm just a Fedora user that got hurt by a devtroll wearing a red hat. I know that some rants on the bugzilla hardly tells anything about a man in general, and one man hardly tells anything about the Red Hat team in general, either. However, as professionals ("being paid to ignore trolls", paraphrasing his own words), he should have done much better!

      We can tolerant problematic software. We know the technical stuff can be fixed in time and we try to help by occasionally writing bug reports and patches and submitting them to the bugzilla. But some response from the devs are just outrageous. We want updates, not flames!

    2. Re:To quote Richard Hughes: by Luke+has+no+name · · 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.

    3. Re:To quote Richard Hughes: by MSG · · Score: 2, 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.

    4. Re:To quote Richard Hughes: by jim_v2000 · · Score: 1

      The problem is that a good amount of the Linux community is paranoid, insane, or both.

      --
      Don't take life so seriously. No one makes it out alive.
    5. Re:To quote Richard Hughes: by David+Jao · · Score: 2, 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 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.

  14. Controversial controversy by Fdisk81 · · Score: 1

    Do /. writers get paid by "controversy"?

    1. Re:Controversial controversy by u38cg · · Score: 1

      No, but they are paid per ad click, which is directly correlated with page views. How do you increase page views? Get people to comment. How do you get them to comment? Post "OMG abortion is teh wrong" type stories and sit back and enjoy the ensuing shit-storm as your users compete to view as many ads as possible^W^W^W^W^W^W discuss civilly the issues raised by the fine post.

      --
      [FUCK BETA]
    2. Re:Controversial controversy by AdamWill · · Score: 1

      Do /. writers get paid by "controversy"?

      I submitted the initial story, but they edited it a bit a before publication. I'm _sure_ it didn't have three 'controvers*' in it, but I can't prove it to you, I didn't keep a copy of my submission. It _was_ pretty late last night. Usually I'd shoot myself in the head before writing something that inelegant. :)

  15. Placeholder post for obscure and obtuse comments.. by Anonymous Coward · · Score: 0

    ...on a topic that nobody outside of the Linux "community" will care about. Please use a minimum of 1000 words to: 1) Nitpick any or all talking points discussed in TFA to the nth degree. 2) Illustrate your Linux expertise by telling us how it is better than other OS's by providing an example of how you took a task that took 2 hours to do in Windows down to just 20 minutes in Linux.

  16. And the announcement got it wrong by Antique+Geekmeister · · Score: 2, 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.

    1. Re:And the announcement got it wrong by pembo13 · · Score: 1

      > 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

      --
      "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
    2. Re:And the announcement got it wrong by Sir_Lewk · · Score: 1

      Exactly, if we are including custom configurations into our logic, they could just revert this fix entirely, nullifying the entire story!

      --
      "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
    3. Re:And the announcement got it wrong by Peter+H.S. · · Score: 1

      This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.

      kpackagekit is for those who doesn't install software from the command prompt but prefer a "click-and-drool" interface, so 'sudo' isn't an option.
      Besides that, 'sudo' has a very coarse security model, you can either install all kinds of software with 'sudo yum/apt/rpm etc' or nothing at all. kpackagekit allows for a much finer and more secure model, like only allowing the user to install signed packages from approved repos when logged in from a local console which can be a good security compromise for some user cases.

      --
      Regards

    4. Re:And the announcement got it wrong by MSG · · Score: 1

      The announcement is correct. PackageKit requires the root password, not the user's own, to add or update packages from the local console.

    5. Re:And the announcement got it wrong by mattdm · · Score: 1

      This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.

      No. PackageKit will still use PolicyKit. The change is that it will now require "auth_admin", which does indeed require the input of the root password. (This is like sudo configured with the rootpw flag in sudoers.)

      It would also be possible to configure PolicyKit to require "auth_self" (or auth_self_keep, which remembers that you authenticated for a few minutes), which would provide sudo-like behavior. But that wasn't done.

      So the announcement is right.

      Arguably, the current (i.e., old again) behavior isn't right and a sudo-like setup should be the default -- but that's a FutureFeature.

    6. Re:And the announcement got it wrong by Antique+Geekmeister · · Score: 1

      No, sudo is not a "future release". It's what works now and has for years. There seems little reason to switch to this new "PackageKit" infrastructure when the existing tools work well for many thousands of users worldwide, especially if hte new architecture is going to pull this kind of ill-thought-out stunt.

      So it looks like the best "one line fix" is simply "yum remove PackageKit". I see nothing in its related dependencies that I actually want installed: do you?

    7. Re:And the announcement got it wrong by Antique+Geekmeister · · Score: 1

      No, in most cases, people didn't ask for and do not use "PackageKit". Most users use "sudo" or otherwise log in with root privileges to do such software installations. It's worked for years, and inventing another "fine-grained cross-platform" is like inventing yet another replacement for /bin/sh. Your time is better spent learning the existing tool than creating another tool to repeat the same errors with and relearn the same harsh lessons (like this one about doing surprise security default changes).

    8. Re:And the announcement got it wrong by AdamWill · · Score: 1

      Amazingly enough, the developers of PolicyKit are aware of the existence of sudo. You wouldn't've thunk it, but they are. As I've already explained multiple times in this thread, the principle advantage of PolicyKit over sudo (and su) is that it provides a framework through which you can design apps such that only the code that actually _needs_ root privileges gets it. Rather than running the entire GUI as root. The secondary advantage is that it provides far more flexibility and granularity in terms of exactly what authentication methods are used to authorize what operations. As I said to the other guy, please do some research.

    9. Re:And the announcement got it wrong by Antique+Geekmeister · · Score: 1

      Well, yes. You can make amazingly sophisticated and fine-grained resolution of control to system functions.

      But why would you want to? It's a complex layer of functionality that seems extremely unlikely to be maintained in the field, serves little noticeable compared to the modest granularity of existing tools, and seems extremely likely to be simply ignored by most users. It requires, as we just saw, considerable attention to unexpected behavior for people who didn't ask for it, and by attempting to be a "fine-tuned cross-platform tool", is bound to interface, and fail to interface correctly, with the current, simple tools. Moreover, it creates an _entirely new set_ of security requirements to test for. SELinux was bad enough and broke enough working software, this closes few holes that people actually need to close and raises the serious issue of potential vulnerabilities in PackageKit being, themselves, crackable.

      A basic analysis on this tool says "don't install it".

    10. Re:And the announcement got it wrong by AdamWill · · Score: 1

      It's not a layer of functionality at all, it's a tool for defining policies (hence the name). It only _does_ anything if applications choose to use it to do privilege escalation (rather than using su or sudo or something else). They would choose to use PolicyKit for the reasons I indicated: so that they can do privilege escalation on a finer-grained (and hence _safer_) level than that of the entire process, and so they can use a wider range of authentication methods than just 'type someone's password'.

      (it's also a far better architecture for typical desktop use than su and sudo, which are essentially console commands with rickety add-on GUI layers).

    11. Re:And the announcement got it wrong by Antique+Geekmeister · · Score: 1

      Again: why is finer grained safer? Because if it can't _block_ the use of su and sudo, and the suid, which are decades old and understood, why ever would I as a programmer writing a new application waste even a single cycle bothering with yet another layer of complexity that can be done _wrong_ as this case was? Once again, what use are the policies for the average programmer or sys-admin? It can only _grant_ fine grained access: it can't block the existing resources, and for almost all cases, the existing granularity is sufficient if you bother to use it.

      No, I don't see it happening except for a few dilettantish applications which are likely to get it wrong and create unexpected and unannounced holes. The complexity, and additional layers themselves are their own vulnerability.

    12. Re:And the announcement got it wrong by AdamWill · · Score: 1

      "Again: why is finer grained safer?"

      For the fifth time, because it means you don't have to run entire programs with root privileges.

      You've got a million-line-of-code GUI program which only actually needs root privileges for the two hundred lines of code which deal with application installation. What's safer - running a million lines of code with root privileges, or running two hundred?

      Not to mention that it provides a much better user experience; you could, for instance, port Nautilus to PolicyKit. That way if you try to rename a file in /usr/local with nautilus open as a regular user it could simply prompt you for appropriate authentication rather than just not being able to do it and requiring you to run a new instance of Nautilus as root before it'll work. Same applies to any application which can do useful things as a regular user but _also_ do useful things as root.

  17. A sensible compromise by Lemming+Mark · · Score: 3, 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.

    1. Re:A sensible compromise by blueg3 · · Score: 2, 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).

    2. Re:A sensible compromise by Anonymous Coward · · Score: 0

      Role Based Access Control anyone?

    3. Re:A sensible compromise by Lemming+Mark · · Score: 1

      Yes, though I don't think Fedora configures sudo access for users by default unless things have changed? But even if I were right about that, it could at least be set up by the administrator in order to avoid giving out the root password, which is probably still a good thing (though if sudo is configured to allow a user to run any command with it then I'm not sure that protecting root's password is that beneficial?).

      The minimum thing I'd want to see *by default* is probably that a user has to type in *a* password, or even just click a UAC-style "yes, really do this privileged thing" through an interface that can't be intercepted by malware. Being able to silently install software would be really useful but only if the system's owner / administrator knows they've allowed for it. Unless, possibly, the packages that a user could install without verification were limited in certain ways (e.g. no setuid apps, can't use more than a certain disk quota)

      Very much agreed that package managers really ought to support (by default IMO!) the ability to install to a user's homedir, whether or not that user has the ability to perform a system-wide install. I'm fed up of having to install stuff from source (without dependency management) just because I only want something in ~/.

    4. Re:A sensible compromise by AdamWill · · Score: 1

      Very much agreed that package managers really ought to support (by default IMO!) the ability to install to a user's homedir, whether or not that user has the ability to perform a system-wide install. I'm fed up of having to install stuff from source (without dependency management) just because I only want something in ~/.

      High-level package managers generally don't expose that functionality because many packages aren't really built to expect it. In theory packages should be perfectly relocatable, but in practice most maintainers never test installing them anywhere but / , and they tend to do things based on the assumption they'll be installed to / and by a process with root privileges (for instance, updating certain databases in %post scripts wouldn't make much sense for a package being installed as a user). If you want to dice with death, though :), you can do it via rpm. 'rpm --root ~/some_directory -Uvh (packages)' should do the trick. You can also do it with yum - 'yum --installroot=~/somedirectory'. I haven't tried this, so I'm not sure what gotchas are involved, but the concept is there.

    5. Re:A sensible compromise by Lemming+Mark · · Score: 1

      I have had the impression that packagers generally don't provide for non-/ installations; my "really ought to support" phrase was intended to include the packagers themselves but I probably should have stated that explicitly, since that's where a chunk of the real problem probably lies.

      I actually thought I remembered rpm having an ability to specify a number of allowed locations for install, so that the packager could say where they could cope with it going. I might be making that up, though, or maybe it isn't relevant. I'm also not sure quite how it'll handle permissions - will it degrade gracefully for files that would normally be owned by users or groups that the installing party does not belong to?

      My worry with the yum --installroot thing - will that just install the package requested if its dependencies are available elsewhere on the local system? Or is it going to pull in a whole Fedora for me :-(

    6. Re:A sensible compromise by AdamWill · · Score: 1

      I dunno, really, like I said, I haven't tried it :) why not play around with it in a VM - for bonus credit, in several different distros - and write up an article / blog post on the results? I'd sure find that interesting.

    7. Re:A sensible compromise by jim_v2000 · · Score: 1

      What's the difference between typing the password for the root account and typing your password for sudo, which gives you root privileges?

      --
      Don't take life so seriously. No one makes it out alive.
    8. Re:A sensible compromise by blueg3 · · Score: 1

      Only one of those requires that the user know the root password.

      This is useful if you have two users that you want to have root privileges -- particularly considering that you can restrict what operations a sudo user can perform.

  18. Re:Finally!Pre-Christmas gift, shoes,handbags,ugg by Anonymous Coward · · Score: 0

    Wow, actual spam on Slashdot. Don't think I've ever seen that before.

  19. sound by Anonymous Coward · · Score: 0

    The pulse audio cramfest was even worse.

  20. Tempest in a teapot by caseih · · Score: 1

    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 limited account for the kids and using policykit to lock down what they can run (no terminal, etc), is one would do anyway. So bringing up security in the context of "users" is really a red herring here.

    Even more ironically, most of the comments seem to indicate that sudo is a recommended solution! Are you kidding? How is that any better for admins and users? If a user wants to do something that needs more privileges, you grant him carte blanche root access? Even on OS X the access controls are this coarse. If the user is "administrative" he has full root access. The Fedora default made a lot of sense for home users but could easily be changed for other environments, though Fedora just doesn't belong in most enterprises.

    What Fedora probably needs to do (maybe they have) is introduce templates for use when creating users. So you can easily create admin users, restricted users, etc. Slashdot users seem to have no complaint about the fact that you absolutely do *not* need root on OS X to install software. And even worse you can install software that's not cryptographically signed!

    1. Re:Tempest in a teapot by Tim+C · · Score: 1

      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 people to sudo anything they want, but that is by no means the only option.

    2. Re:Tempest in a teapot by goarilla · · Score: 1

      not only that sudo can be configured to run commands as another user instead of root, it
      can also be configured to disable shell escapes so :! /bin/sh doesn't work in vim

    3. Re:Tempest in a teapot by caseih · · Score: 1

      Yes this is true. But it's still coarse. You can restrict what binaries are run, yes. But what about things like controlling access to removable devices? Clearly sudo isn't enough. In fact in the long run PolicyKit will completely replace sudo. So sudo serves some good purposes, particularly in the realm of system administration. But let's not mistake it for a solution to the core problems of security on modern desktop systems.

      Anyway, if you want to lock down Fedora for a user, you configure PolicyKit to disallow software installs (just in how you can designate a user in OSX to not be administrative). Personally I'm going to tweak policyKit to turn *on* installation of signed packages on my system.

    4. Re:Tempest in a teapot by jim_v2000 · · Score: 1

      Don't you be bringing the obvious logic into this discussion!

      --
      Don't take life so seriously. No one makes it out alive.
    5. Re:Tempest in a teapot by petrus4 · · Score: 1

      Instead you'd do CentOS 5 or Ubuntu LTS.

      CentOS maybe, but instead of Ubuntu, a smart admin who doesn't want hardware problems in particular is going to use Arch.

      Ubuntu is not stable.

  21. only temporary by Anonymous Coward · · Score: 0

    It looks like they plan on changing it back for upcoming releases. Tehehehe! Get out your flame throwers!

    The idea was that the change in PolicyKit would be accompanied by a
    default set of roles, and a nice user interface for assigning users to
    roles. Unfortunately, with the constraints of time, it became clear that
    this all (and especially the GUI) wasn't going to be there for Fedora
    12. So, PackageKit needed a fixed policy for all users. For each action
    (install signed packages, install unsigned packages, remove packages,
    etc.), it needed to allow, deny, or ask for the root password.

    and

    In upcoming Fedora releases, we expect to finish both the default set of
    policy roles and the user interface components to provide the full
    experience that was originally planned.

    So redhat still plans on making this change. They are just waiting till they implement the GUI to easily change a user's role.

    1. Re:only temporary by AdamWill · · Score: 1

      So redhat still plans on making this change. They are just waiting till they implement the GUI to easily change a user's role.

      Well, um, then it's not going to be the *same* change, is it? The point is that you'll be able to choose what kind of role a new user account has, and hence what actions it'll be able to do. A regular, non-admin user account won't be able to install software this way.

    2. Re:only temporary by TheCycoONE · · Score: 1

      Good, particularly if it defaults to requiring the root password.

      For those that don't know, Fedora 11 already had an interface where administrators can change whether numerous other actions require a root password (and whether it requires it every time or just the first time.)

      Extending that to include installing signed packages gives the administrator of a system the ability to choose for their system whether they trust users to install packages without contest or not.

      I think the only problem with F12 was that they turned the feature to the less secure option by default. It didn't help that the interface for changing it was relatively hidden.

  22. Re:Finally!Pre-Christmas gift, shoes,handbags,ugg by Tim+C · · Score: 1

    It (or similar) has been showing up on pretty much every story I've read on here for the last few days.

  23. It is still a good idea for certain users by Anonymous Coward · · Score: 0

    It is still a good idea for certain users to install packages.
    Perhap a trusted group.

    If only root can do it, then everyone is using sudo, and you system is less secure.

  24. but.. by Anonymous Coward · · Score: 0

    i'd be happy if they fixed the checksum file which incorrectly states the sha256 hashes are sha1.

    1. Re:but.. by AdamWill · · Score: 1

      i'd be happy if they fixed the checksum file which incorrectly states the sha256 hashes are sha1.

      It doesn't. It states that the signature on the CHECKSUM file is SHA-1, which it is. The file is signed with an SHA-1 signature, the checksums themselves are SHA-256. This is admittedly somewhat confusing, and will be changed to be less so in Fedora 13. But it's not incorrect.

  25. Re:It's nothing new from them. by Anonymous Coward · · Score: 0

    Yay, a troll!

    They've done a great job at appealing to the morons and fucktards of the Linux community.

    Aww, how cute! Ain't you the cuddly one.

  26. Non-controversial removal of misfeature by SgtChaireBourne · · Score: 1

    You basically had to be logged into the console.

    Or go to the trouble of faking that. It got spotted reasonably quickly and fixed fast enough after it was spotted. That's working more or less as it should What is broken is how did such a misfeature even get in there in the first place?

    --
    Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
  27. Almost sounds like Ulrich Drepper by jonaskoelker · · Score: 1

    "You missed the "in my opinion" line in your reply." [and others]

    Heh... I half expected to see Ulrich Drepper's name in the bug discussion (famous for his glibc controversy regarding support for those fishy "Carp Architectures").

    None of that real trolling then, I see ;-)

  28. Re:Finally!Pre-Christmas gift, shoes,handbags,ugg by spartacus_prime · · Score: 1

    It must be kdawson's side job.

    --
    If you can read this, it means that I bothered to log in.
  29. Not a Bad Idea by Anonymous Coward · · Score: 0

    Personally, I get annoyed when I get prompted every time I need to make a minor change to my notebook. Why can't I even mount a directory without modifying fstab? Not to mention having to set special permissions so that my limited user can use the directory once it's mounted.

    Linux needs a sensible privilege system. Most of us aren't in corporate high-security and uptime environments; give us a break.

  30. Read through the bug report... by Logic+Worshipper · · Score: 1

    And it was worth reading through all comments on the bug report for this...

    Comment #224 From Andrew Gormanly:
    It's a bug in the thought process of the maintainers, which shows up a bug in the security processes of the distro.

    How perfectly eloquent.