Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Red Hat Software Security Unix Linux

Fedora 12 Lets Users Install Signed Packages, Sans Root Privileges 502

eqisow writes "The new default policy for Fedora 12 allows local, unprivileged users to install signed packages without root access. This change apparently went mostly unnoticed until after the Fedora 12 GA release, at which point it sparked a mailing list thread that is, as of this writing, over 100 posts long."
This discussion has been archived. No new comments can be posted.

Fedora 12 Lets Users Install Signed Packages, Sans Root Privileges

Comments Filter:
  • Re:It's obvious (Score:3, Informative)

    by junglee_iitk ( 651040 ) on Wednesday November 18, 2009 @05:36PM (#30149030)

    Or you could install RHEL

    That is what they want, apparently: []

    "Should the defaults be targeted towards home users or corporate desktop
    considering the short lifecycle of Fedora and the target audience? I am
    not sure there are corporate deployments but wouldn't they be heavily
    customized their desktop deployments and kickstarting it anyway?"

  • Re:This makes sense (Score:5, Informative)

    by fluch ( 126140 ) on Wednesday November 18, 2009 @05:48PM (#30149162)

    No, it does NOT make sense. It creates a new security risk: If some malicious software (runing under with normal user privileges) notices that a hackable software is missing on the computer (one which has a known security vulnerability to gain root access) it can now install this package without problem and gain root access later on.

    A sudo approach like done in Ubuntu is much better.

  • by Defiler ( 1693 ) * on Wednesday November 18, 2009 @05:54PM (#30149236)
    I know of one for Mac OS: []
    It would probably not be much of a challenge to make that work on a Linux machine. That and a Linux tool for this probably already exists.
  • by Eric Smith ( 4379 ) on Wednesday November 18, 2009 @05:57PM (#30149274) Homepage Journal
    It's more of a risk because a package can install setuid binaries, or install config files in directories such that they that are used or interpreted by processes running as another user or root. Installing a package can do a lot more than you can do as an unprivileged user.
  • by BountyX ( 1227176 ) on Wednesday November 18, 2009 @06:03PM (#30149338)
    Browsed through the list. Here are instructions to require a password for signed repo []. I agree with many of the mailing list users, this is a very bad default and there seems to be an assumption of targeting the desktop, or single user environments...
  • Hmm... (Score:4, Informative)

    by fuzzyfuzzyfungus ( 1223518 ) on Wednesday November 18, 2009 @06:04PM (#30149354) Journal
    I'm not sure that this is a good default setting(though I would say that it is much more defensible for a desktop oriented distro, with the ability to turn it off; while it would be unsuitable for a server/corporate lockdown box setup). However, aside from the on by default/off by default question, I don't really understand what the big deal is.

    Some people are freaking out, as though context-sensitive privilege escalation is some sort of ghastly betrayal of all that is UNIX and Good(tm). That seems frankly nonsensical.For example, good old Sudo does exactly that. If you are on the sudoers list, you can do some or all things as a different user(usually root) with just your own credentials. This is wildly useful, and is a routine part of a great many UNIX systems. In desktopish contexts, we've also had things like automounters for external storage, doing a limited amount of trusted stuff as root, for some years now. Not necessarily the thing for servers; but usually good for desktops.

    I don't know whether this is a good default or not, and I'd certainly want to see it mentioned in the docs(assuming it isn't already, haven't checked). However, limited privilege escalation mechanisms, for performing a set of trusted actions, have been part of UNIX for years. Anybody who is merely blowing up about that, rather than about the defaults question, is being reactionary in a way that isn't even accurate.
  • Re:This makes sense (Score:1, Informative)

    by Anonymous Coward on Wednesday November 18, 2009 @06:11PM (#30149450)

    Use your head man! If any single bug is found in any signed kernel driver anywhere ever, a piece of malware will auto-fetch the signed driver (or just come packaged with it), install the said buggy driver (no su access needed!), and promptly exploit it to gain root access for itself.
    Any signed buggy driver will be a gaping security hole until it's signed status is somehow revoked - and until it is revoked, ANY program can use it to get kernel mode access. This has all the makings of an permanent security hole.

  • Re:YAY!!!! (Score:2, Informative)

    by Anonymous Coward on Wednesday November 18, 2009 @06:14PM (#30149482)

    Windows UAC was lambasted because the implementation was terrible.

  • by QuoteMstr ( 55051 ) <> on Wednesday November 18, 2009 @06:15PM (#30149498)

    There's something really, critically important here that everyone is missing:


    In other words:


    That means that a random user can't ssh into your server and install packages. He has to actually be at the machine. And if he has physical access to the machine, he can just boot from a LiveCD.

    Installing signed packages is a very low-risk operation. Yes, there are theoretical vulnerabilities, but in order for them to make much of a difference, you need the perfect alignment of coincidences that's really unlikely in practice.

    This change allows users who can already compromise the machine given enough time do something very safe painlessly.

  • Re:YAY!!!! (Score:1, Informative)

    by Anonymous Coward on Wednesday November 18, 2009 @06:16PM (#30149508)

    Microsoft got lambasted because the UAC started out as sudo from an alternate, evil universe not unlike bearded Spock's home. It got better after SP1 was released, but it still proves the adage:

    Those who fail to learn from UNIX are doomed to re-implement it... poorly.

  • by Anonymous Coward on Wednesday November 18, 2009 @06:22PM (#30149584)

    Nix ( You have to have your own glibc, though. As a bonus you can have a few of them without conflicts.

    By the way, we allow non-root users to install software - any software. Now, the semantics is such that it doesn't really give user something he couldn't achieve by manually writing a binary: setuid wrappers and upstart jobs are enabled/disabled by root by a process similar to installing packages, but distinct enough. Yes, you can install sshd - you could download a statically compiled version with the same success.

  • by Anonymous Coward on Wednesday November 18, 2009 @06:24PM (#30149618)

    Gobo rootless might be of interest? []

  • Re:This makes sense (Score:3, Informative)

    by the_womble ( 580291 ) on Wednesday November 18, 2009 @06:26PM (#30149652) Homepage Journal

    The thing is that Linux does not require the root password to do everything. The commonest task that requires it is installing software.

    From what I understood of the complaints about Vista, it required the root password a lot more than Linux does.

  • by Captain Segfault ( 686912 ) on Wednesday November 18, 2009 @06:34PM (#30149778) Homepage Journal

    The big security issues are with services and suid/sgid binaries. As long as installing the package doesn't cause any other users to run that code it shouldn't be any more of a problem than letting the user run their own code. Those probably should require root to install.

    This isn't 100% watertight but would drastically reduce the scope for local root exploits.

    It'd be stupid to have this policy on a server, obviously, but it doesn't seem to be that absurd at all for desktops/workstations.

  • Re:YAY!!!! (Score:4, Informative)

    by natehoy ( 1608657 ) on Wednesday November 18, 2009 @06:37PM (#30149830) Journal

    Yes, because as everyone knows, whenever ANYONE speaks about Linux, it's the SAME person who made another previous statement about Linux.

    UAC is an excellent attempt at a Windows implementation a proper security model (temporary escalation of authority for a specific task, with prompting). Personally my only complaint about UAC was that it took Microsoft so long to finally come around to something like it. I run XP as a limited user, and it's very frustrating to see all the software that has been written for Windows that assumes you are running as Admin simply because that's the Windows XP default.

    And, yes, I'm clearly and keenly aware that Microsoft is not responsible in any way for the laziness or incompetence of third party developers who write code that runs on their OS. But it does point back to the whole issue that's plagued Microsoft all along - security was ignored for way too long in Redmond, and continued as an oft-ignored afterthought well after they had gained a reputation for writing insecure code. I will give them credit - once they finally extracted cranium from anus and got the clue meter off zero, they made a relatively impressive turnaround in security in a very respectable amount of time.

  • by EvanED ( 569694 ) <[moc.liamg] [ta] [denave]> on Wednesday November 18, 2009 @06:45PM (#30149952)

    One of my friends has even more stuff installed locally than I do; he gave GoboLinux a try a while (few months?) ago but found the rootless mode "fragile:"

    (4:38:11 PM) me: what were your objections to gobolinux's package manager? remember?
    (4:38:36 PM) him: oh
    (4:38:53 PM) him: The environment it set up was really fragile
    (4:39:00 PM) him: I broke it several times
    (4:39:09 PM) me: environment variables you mean?
    (4:39:11 PM) him: Lots of the pkg config stuff didn't end up being found properly
    (4:39:29 PM) him: yeah - rootless mode just isn't tested enough and not quite robust
    (4:39:34 PM) him: like you couldn't change PATH and LD_LIBRARY_PATH much or what?
    (4:40:53 PM) him: It wasn't picking up libraries that you installed with it properly because it broke pkgconfig files
    (4:41:57 PM) him: More specifically, the directory structure they use is cool but they never patched the pkgconfig files, so pkgconfig was always wrong and not much works

    I can't speak from personal experience, and I suppose things could have changed since then, but he did drop back to manual compilation.

  • by huge ( 52607 ) on Wednesday November 18, 2009 @06:55PM (#30150132)
    "Physics is to mathematics as sex is to masturbation"

    - Richard Feynman

  • How to disable it... (Score:2, Informative)

    by sten ben ( 1652107 ) on Wednesday November 18, 2009 @07:09PM (#30150316)

    Here's a blog post on how to disable it: polkit and package kit and changing settings []

    I might be getting a bit conservative in my old age but what of what is explained in that post is better than visudo?

  • by Znork ( 31774 ) on Wednesday November 18, 2009 @07:22PM (#30150484)

    A more 'correct' way to disable would probably be something like what's described here [].

    Editing the package-kit rules also seems to make it possible to obtain some finer granularity that doesn't seem as unpalatable as sometimes inappropriate general install rights.

  • by Romancer ( 19668 ) <romancer@deathsdo[ ]com ['or.' in gap]> on Wednesday November 18, 2009 @07:25PM (#30150526) Journal

    They're in for a long battle.

    Considering that the fix to this is already written out in one line of code in the same thread on the same day here: []

    And they have already admitted that the default security setting is not consistent with the philosophy they had built the Linux system on in the past. That's a pretty good turn around time for a mistake in the security area of an OS.

  • Re:This makes sense (Score:4, Informative)

    by jmorris42 ( 1458 ) * <> on Wednesday November 18, 2009 @07:55PM (#30150856)

    > Wow the FUD flies fast and furious here.

    > I doubt very much that most Fedora installs even have an administrator, or serve more than a home user.

    So many words from someone who can't read. And they said write only devices were mythical. :)

    As stated in my post avove, this isn't so much a change in Fedora as a case of Fedora being the first release with this new policykit. If this isn't stopped, flamed into oblivion, shouted down, whatever, it will end up in Ubuntu, Debian, Suse, eventually everything down to FreeBSD because this *Kit crap is infecting everybody. Or it will be individually patched out by individual package maintainers and we all know that is sub-optimal.

    And yes even Fedora has users. Even if you are correct that few corporate types will be rolling F12 out to end users there are things called families. I admin my home machine but I'm not the only user. No I don't trust every person I give an account to enough to allow them to have admin rights. Remember trust in the sysadmin sense is more about trust in their skills/knowledge not whether you would loan em a hundred bux.

  • Line crossed.. (Score:4, Informative)

    by Junta ( 36770 ) on Wednesday November 18, 2009 @08:23PM (#30151136)

    I undestood locality to console as an 'authentication' scheme for reboot/shutdown -h now. That is a transient state change with, in theory, no lasting effects on the underlying platform. The slight risk of temporary DoS is taken understanding that the user would otherwise resort to ungraceful use of the power button.

    I understand the use for removable media, where the owner of auto-plugged media is assigned to the 'console' user. Persistent state change is possible, but restricted in scope to a removable device that someone at a 'console' controlled physically anyway.

    However, this is a mechanism that allows a user to make persistent state changes to the 'root' owned content. This is simply not acceptable. The act of installing software is rare enough so the password shouldn't be considered horrible, and no worse alternatives are likely if a user cannot install the software conveniently.

  • by Celeste R ( 1002377 ) on Wednesday November 18, 2009 @08:26PM (#30151176)

    RH didn't give any go ahead, it was the PackageKit upstream that did it without any communication.

    NO documentation about this 'feature'.
    Terrible configuration system.
    Also, the entire mailing list had to do their own homework about this policy.

  • Re:This makes sense (Score:3, Informative)

    by Sir_Lewk ( 967686 ) < minus herbivore> on Wednesday November 18, 2009 @08:52PM (#30151434)

    Yum won't allow unpriviledged users to install things, those guys aren't idiots.

    Ah contraire. If you read the mailing list you will see that one of the idiots supporting this madness is Seth Vidal, the lead developer and maintainer of Yum.

  • Re:It's obvious (Score:3, Informative)

    by Dahamma ( 304068 ) on Wednesday November 18, 2009 @09:11PM (#30151618)

    Must have been a while since you last checked ;)

    Very few if any network services are enabled/started by default when installed on Fedora. Probably because as you said it is a fairly bad practice...

  • by agrif ( 960591 ) on Wednesday November 18, 2009 @09:14PM (#30151660) Homepage

    Like when? Few (at least semi-professional) Windows programs behave that way. (Visual Studio is a pretty notable exception; it demands to install a couple hundred megs of stuff on your system drive.)

    The difference is in Windows, each program usually has it's own specific directory that can be put just about anywhere, but the executable usually has to be started with a specific working directory, or the executable itself has to be in it, etc.

    Linux, and Unix in general, has a strong, historical file system structure that places binaries in specific places, configuration in specific places, and everything else in it's own place. There's even hierarchies for system, user, and computer-local files. Binaries are expected to run with any active directory, from a location that houses all the binaries on the system, and nothing else. A hardcoded path to, say, /etc/awesomed.conf is required!

    For trivial cases (applications with no external data) the binary can be moved willy-nilly and still work. You can even move libraries, and update your ldconfig search path. However, often programs expect their data to be in one specific place, determined at compile time, or determined by a fixed-location configuration file. Sometimes you can get around this with small hacks, but not in any way it would be easy for a package manager to do.

    Of course, the advantage to this strict structure is that hardcoded paths are almost always correct. Apart from that, it's up to individual preference as to whether Windows or Linux handles this better.

    (Now when I say hardcoded, I of course mean compiled-in. I'm not trying to suggest there's just some unchanging string literal in the source, just that there's probably some generated string that gets compiled in after configuration.)

    Emerge has a ROOT variable you can set; presumably this gets passed to configure --prefix. However, I don't know of any way to run Portage without root, and can't find anything about running it on systems that aren't Gentoo.

    It's been a while since I've worked with Gentoo, but I vaguely remember it's possible to run emerge as non-root, and I definitely remember something about a Cygwin port of it, so that's definitely possible.

  • by Anonymous Coward on Wednesday November 18, 2009 @09:19PM (#30151714)

    zero install:
    You run an app through it (using its URL, eg: 0launch ), and it will install it to a path under your home directory if it isn't already there, and then run it. Not much third-party software available via it yet, but there's an effort in place to change that.

  • by Anonymous Coward on Wednesday November 18, 2009 @09:22PM (#30151730)

    The assumption is that *signed* packages are only coming from a trusted source (i.e. the user cannot install their own homebrew package).

  • It is an irony... (Score:3, Informative)

    by drolli ( 522659 ) on Wednesday November 18, 2009 @09:23PM (#30151740) Journal

    that many posters here see this as a security bug "because it enables you to install any exploit found in any package". That is true and untrue at the same time. A good idea would be that no user may create a setuid root binary. But all escalations based on system call implementation errors can be provoked by the user himself by picking out the right code from the source of the packages and compiling it himself using the gcc which is most likely available on many systems.

    An even better idea view would be an per-user-view of the computer.

  • by Anonymous Coward on Wednesday November 18, 2009 @09:43PM (#30151892)

    Yes. Gentoo Prefix [].

    It has all of the functionality of Gentoo's package manager, Portage, but can be run by an unprivileged user.

  • by jroysdon ( 201893 ) on Thursday November 19, 2009 @12:42AM (#30153036) Homepage

    System - Administration - Add/Remote Software
    Games - [x] abe

    Installed abe (Scrolling, platform-jumping, ancient pyramid exploring game) without any password at all on F12 (not user, nor root). It was not installed in the user directory, it was installed the same as if "yum install abe" was executed by root, solving dependencies as well.

    I see others discussing how to solve this via polkit. Another solution for my multi-user systems where non-admins shouldn't be mucking around, I see the simple fix as removing PackageKit: rpm --erase gnome-packagekit. If you want to go to the extreme: yum --erase PackageKit.

    This also disables notifications of new software releases, but software updates can still be managed with yum and automation could occur with yum-cron.

  • Re:It's obvious (Score:3, Informative)

    by PeterBrett ( 780946 ) on Thursday November 19, 2009 @02:35AM (#30153512) Homepage

    Trusting the repos has nothing to do with it. If I've got my users on Fedora as their desktops, I don't want them installing packages that I don't know about. Why should the average user have a web or FTP server running on the desktop? Default configurations have frequently been the location for vulnerabilities, and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.

    I agreed with you about this, so I investigated. It turns out that daemons packaged by Fedora are disabled by default, and require someone with root access to enable them. A package won't pass review if that's not the case.

    The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.

  • Re:Wow (Score:3, Informative)

    by Antique Geekmeister ( 740220 ) on Thursday November 19, 2009 @05:18AM (#30154112)

    You need the package to have a signature that is already registered. Fedora 12, like early Fedora releases, doesn't register _any_ GPG keys for RPM until after manual authentication by the user. "yum install" asks for this during software installation. Unfortunately, many sites that deal with signed packages don't protect their signatures well, and it's dificult to tell which signatures for RPM are installed or appropriate. So it's a vector, just not as bad of one as you note.

  • It's Official... (Score:3, Informative)

    by nathanh ( 1214 ) on Thursday November 19, 2009 @08:02AM (#30154716) Homepage

    ... Red Hat is now hiring idiot developers who don't know the first thing about UNIX.

    The Linux admins at one of the sites I regularly work were in a furor over this change to Fedora. Within the space of a minute they had concocted a half dozen ways this "feature" could be exploited. This wasn't even taking into account the management and maintenance nightmare of machines where users could install software; they were simply considering the security implications. One of the admins was so furious that he suggested in all seriousness that the site drops Red Hat Enterprise Linux immediately and use SUSE Enterprise. His justification being that if Red Hat can allow this kind of stupidity into their community build, imagine what sort of crap is filtering through into Enterprise Linux. He no longer has any confidence that Red Hat has the faintest clue what constitutes a secure system. I didn't think he was overreacting; this is the dumbest thing I've seen any Linux distribution do, ever.

    That the Fedora developers are trying to defend this stupidity is just the icing on the cake. Red Hat should sack every last one of them for incompetence.

  • Re:This makes sense (Score:3, Informative)

    by TheRaven64 ( 641858 ) on Thursday November 19, 2009 @08:16AM (#30154758) Journal
    It's different in a few ways. Firstly, this can install daemons and other setuid binaries that will run as root. If any of these have a security hole then the user can install them, exploit them, and gain root. Not good. The other is that they all go into the default path for every other user. That means that other users can run them accidentally.
  • by Errtu76 ( 776778 ) on Thursday November 19, 2009 @08:19AM (#30154770) Journal

    according to Seth Vidal:

    $ pklalockdown --lockdown org.freedesktop.packagekit.package-install

    Ref: []

  • by marciot ( 598356 ) on Thursday November 19, 2009 @10:11AM (#30155640)

    Not so for packet sniffers. Putting the NIC in promiscuous mode requires root privileges. The way wireshark gets around it is by requiring a service to be installed under root that then allows regular users to access the NIC through the service.

  • Re:sounds good to me (Score:3, Informative)

    by Antique Geekmeister ( 740220 ) on Thursday November 19, 2009 @10:28AM (#30155864)

    You sign the package, yourself, with a stolen key. Since a local site repository may have far less security than a major repository like RedHat, and even RedHat has been compromised in the past (, simply installing packages for any random user should not be permitted. In particular, the ability to install out-of-date, previously compromised, but previously signed packages without administrative privileges should be blocked.

  • by Professional Slacker ( 761130 ) on Thursday November 19, 2009 @12:32PM (#30158188) Homepage

    I'm assuming that PackageKit still requires root to modify shared system areas where the owner is root (e.g. /usr/bin etc.)

    No, that's exactly what people are upset about, that any random account logged in to the physical machine can write to /usr/bin, the things that they can write are limited to the contents of signed packages, but that's still a whole lot more than the absolutely nothing they could write under F11. Also all the comments I've seen are about adding packages, but does this also allow removing packages?

1 Angstrom: measure of computer anxiety = 1000 nail-bytes