Slashdot Mirror
Fedora 12 Lets Users Install Signed Packages, Sans Root Privileges
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."
Sounds like I need to upgrade to Windows 7 for some real security...
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
...all those laid off Microsoft employees already found work.
Or you could install RHEL
That is what they want, apparently:
https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00945.html
"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?"
If the content is trusted then requiring the user to get root privileges is just a security risk (key-loggers). I do hope, however, that they had to foresight to require specific permissions to allow users to install signed packages. I don't want my guest users installing every signed package and filling my HDD.
What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever && make install' but without the complete bitchness of dependency hell -- without any root privileges at all. Anyone know of one?
Certainly there can't be a problem here, says the Fedora team. According to the release notes, there are 15,000 packages which can be installed by these unprivileged users. That's a lot of fscking code -- surely some of it is poorly written. Consider this scenario: Package X suffers a critical {local, remote} root vulnerability. If the vulnerability isn't public, any local user (and maybe remote ones too!) has root. If the vulnerability is public, there is often a long window between downstream fixes and Fedora fixes. In either case, this is a security issue. The Fedora team really should have put this in the release notes and reconsider this implementation in the first place.
Read the response. It's actually a Red Hat employee making the complaint, calling it a security vulnerability. I wouldn't call a Red Hat employee complaining about this policy to a Fedora mailing list an attempt to coax RHEL usage.
Trying to install linux on my microwave, but keep getting a kernel panic...
That is just silly. Users are users for a reason, and admins are admins for a reason. If users want to install software, they can use sudo.
Whoever approved that in the Fedora team needs a refresher in security.
Feed the need: Digitaladdiction.net
Ah yes, the age-old struggle between developers and sysadmins bears yet more sour fruit.
After working as a sysadmin for 10+ years for several groups of Linux software devs, I realized that devs don't make good sysadmins, and vice-versa (in general).
Developer workstations are usually a mess of tweaks, customizations, hacks, extraneous libraries that they were "testing" three months ago, odd daemons, and all kinds of other crap. They would install new packages hourly - so all the better if they could do it without requiring root access to the servers.
Sysadmins on the other hand tend to be uptight control freaks who micro-manage every little thing. This is great when we're talking the company webservers, but when it comes to developer workstations, well... the devs weren't too happy about being locked down.
I guarantee you that this feature was requested/suggested by one or more developers on the team, who thought it'd make their lives easier. And I also guarantee you that most of the people against it are system administrators.
God, I'm glad I went back into Science.
I really don't understand the basis for this move. From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine. Its seemless in Linux and OSX. Not prompting for authentication for signed package installs is insanely insecure and borderline insane.
The email trail even includes a query from a redhat developer asking why its such an issue. Incredible. I was going to quote some of that thread but the entire exchange is pretty funny, odd, and scary. Remind me to continue to not use RH, at least as a server.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Suppose someone wrote a worm that could get access to the system as a user. Then all they need is to find a signed package with a privilege-escalation bug, and whether it's installed or not, the malware could exploit it, gaining root access.
But apart from that, I can see where this would be nice from a single-user system standpoint.
This isn't necessarily insecure. Sure, it's not something you'd want enabled on your servers, but for a desktop the only big problems I see are with disk space. (If, on the other hand, this allows the user to install and start a network-accessible service without root privileges, then it's a problem.) For home users, this feature is a definite convenience, and nothing to worry about. For corporate desktops, it's more of a wash: employees can install productivity apps without pestering IT, but now IT has to disable repos that contain counter-productivity apps.
The reason unix has always required root access in order to install software isn't because that's the way things should be, it's because there hasn't been another way to make it secure. Now, if you trust the distro's repos, you can safely let users install those signed packages. This is similar to (but more secure than) Mac OS X's policy of letting users install and uninstall but not modify app bundles.
Fedora, Now With The Power Of Windows!!!!
Tired of those pesky admin privileges. Tired of using superuser. Want everyone on your system to install what they like, even from websites that say "Install Me!", why Fedora 12 is here! Come on, don't be afraid. Flush forty years of basic security principles down the toilet!
The world's burning. Moped Jesus spotted on I50. Details at 11.
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...
Trying to install linux on my microwave, but keep getting a kernel panic...
The best rant against the Windows way of doing things from Tom Christiansen:
http://slashdot.org/comments.pl?sid=3291&cid=1395315
Truer words were never spoken.
--
BMO
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.
MS is hit hard because they have had similar bad ideas, combined with having hired bad developers (and getting worse). But MS is now focused on Security, and is slowly making progress. I fear that if and when they surpass *nix (Linux, BSD, OSX, and some of the smaller ones like Solaris :) ) in security, that *nix will suddenly be slammed with virus and worms. And it will appear to happen overnight, even though it will be possible openings like this that slowly turn the heads of the writers.
I prefer the "u" in honour as it seems to be missing these days.
There's something really, critically important here that everyone is missing:
ONLY LOCAL USERS CAN INSTALL PACKAGES
In other words:
IT ONLY MAKES A DIFFERENCE FOR USERS PHYSICALLY SITTING AT A MACHINE
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.
Fedora accepts all kinds of packages. You could create a simple utility, like some netmask computation code, make it a trojan (add code which does what it's not intended to do as setuid root).. package it for Fedora. This can go completely unnoticed. As an upstream maintainer, I am pretty sure Fedora or any other distro does not review my project code more than a cursory glance to fix any compilation/integration issues.
User gets to be root user. It may not even be a user.. it may be a program of some kind that has access to your user account after exploiting a vulnerability in an app such as your web browser.
There are other ways to get root too, such as exploit other setuid binaries in any of the thousands of packages that Fedora ships in the Everything repo.
Letting users install packages (signed or not) on a system administered by root is a stupid decision.
Banu
So only 99% of users?
At the bottom of the
Interesting and wrong, I should say:
There's a superficial kind of sense in what he's saying. After all, if someone has console access, he could already pwn the machine, right? Well, the keyword here is defense-in-depth. There are lots of reasons non-root, non-trusted users might want to run from the console. Linux on random net-cafe machines is one example, where all kinds of people use the console. A family PC running Linux (hey, not as farfetched as it sounds) might have different user accounts for each family member.
Sure, it's trivial to fix this with pklocalauthority, but should users have to? It's about as lame as telling folk, "hey, you can just switch off IIS if you don't need it."
It's sad that while Microsoft and Windows has made so many strides towards providing a secure-by-default configuration, Red Hat seems to be losing the plot. Cf another gem of a comment on Bugzilla: I don't particularly care how UNIX has always worked. Sigh.
Go somewhere random
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.
This can theoretically be easily disabled by chmod'ing to everything under /etc/yum.repos.d as 600, and of course making sure that everything there is owned by root. Assuming this doesn't extend to rpm, and my initial tests suggest it may not, then that should be enough to lock it down for the most part. This is preferable to locking down the yum binary since a user could just bring their own binary to the system and then install at will. I'm sure my method could be bypassed but I haven't had a lot of time to test so someone else feel free to test it.
0x09F911029D74E35BD84156C5635688C0
Yeah, but most of those 100 posts were probably actually read before getting responded to
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.
While the Fedora devs seem to think that Package-Kit should be removed from servers, this is, as one poster mentioned, a case where "should" has nothing to do with it. I have an expectation that I have to either use sudo or provide a root password to install even the smallest package. Changes like this render that expectation void without doing a proper job of notifying me, and there are a lot of relatively unsophisticated Linux admins out there. There's only a certain level of coddling that should be done to avoid oversimplifying things, but this breaks a fundamental premise of the Linux world, and I don't recall seeing anything in the installer saying that Package-Kit's installer would work differently.
You can never go home again... but I guess you can shop there.
Unless there simply isn't, e.g., a signed telnetd package, you don't need undiscovered vulnerabilities for this to be a potential for major problems. Many packages are not the sort of thing you would really want to have on, say, a publicly accessible machine, but might be willing to have on a system on your LAN (Samba springs to mind). Beyond vulnerabilities, there's the simple issue of exposure.
If the admin can't define who is allowed to do such basic administration tasks as installing packages, something is seriously wrong!
this basically means "I allow you to install any package which I have signed. You don't need to log in as a more-powerful user to do so, because I have already pre-approved this action, just as if I added the specific command to the sudoers file with no password"
The default signature is that of redhat, but there's no reason to expect the same technique couldn't be used for other signatures. Sounds like a good idea, especially for a corporate environment (single deployment, but if some people need to install Eclipse, they don't need to contact support to do so)
The next step along the line is to tie this into the existing "that command doesn't exist, install Foo to use it", to turn that into "Foo isn't installed, do you want to install it?" and a (sorry) windows-style "how recently was this used?"/auto-remove-during-updates and make the whole operating system feel entirely seamless in terms of application usage.
This is a good thing.
-- 'The' Lord and Master Bitman On High, Master Of All
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?
If you're doing it corporate-style, you should already have a local repo (for bandwidth and security reasons), them lock yum.conf to only recognize your local repo.
Doesn't solve all permutations (e.g. discreet downloaded packages, some idiot installing apt-get, etc), but it solves enough of them to make things sane again.
Quo usque tandem abutere, Nimbus, patientia nostra?
The best rant against the Windows way of doing things from Tom Christiansen:
http://slashdot.org/comments.pl?sid=3291&cid=1395315
Truer words were never spoken.
--
BMO
The trouble is I have encountered both physicians and lawyers who WILL do exactly whatever the customer requests. With lawyers, they often get beaten down by the judge, but they still took the clients money in exchange for bad advice. With doctors, people become over-medicated, misdiagnosed, and sometimes dead.
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.
XML is like violence. If it doesn't solve the problem, use more.
Lots of posters flying off the handle that obviously didn't read the actual thread. PackageKit added this as a "feature" without notifying the Fedora team. yum still behaves as expected. I'm assuming that PackageKit still requires root to modify shared system areas where the owner is root (e.g. /usr/bin etc.), but users can install their own local packages using PackageKit.
In fact, this is exactly what Mac OS X does by default. I'm not entirely sure if this is really a problem or not. In Linux, users are already able to install local apps into their home directories, this appears to just make it integrate with the UI much easier than before. I remember I had to manage my own user apps in my home directory and it was a real pain, since I had to add that bin directory to my path, and none of those apps appeared in menus anywhere.
I've been using redhat/fedora since at least RedHat5, having previously used Slackware. I thought SELinux was pretty sketchy, but this change is utterly ridiculous. I'm still on FC11, but until and unless they develop some sanity by FC13, I'm going to need to find a new distro (CentOS? Debian? I'm not sure yet)
For every problem, there is at least one solution that is simple, neat, and wrong.
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...
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.
Honest question: Do RPM files have a way of distinguishing between system- and user-level software? It seems like a fairly obvious thing to have/check, then users could install safe applications (i.e. those that don't have programs in /sbin or /usr/sbin), for their own uses.
Moreover, why can't RPMs just let users install in a private fakeroot directory (like there home directory). That way they don't have to touch the root file system and can easily install packages without needing a password. (Like if I wanted Eclipse, I could just find the RPM and double click to install it, no password, no fuss.)
I think Fedora could make this right if they wanted to.
The reason unix has always required root access in order to install software isn't because that's the way things should be, it's because there hasn't been another way to make it secure. Now, if you trust the distro's repos, you can safely let users install those signed packages. This is similar to (but more secure than) Mac OS X's policy of letting users install and uninstall but not modify app bundles.
The reason was simply because a user didn't have the privileges to change anything (by default) outside his/her own home directory and the system temporary directory. That is the way it should be -- only changing files that you have permission to change. Allowing users to add or remove software packages in / and /usr is beyond ridiculous. This is why users who want to install software packages themselves, can only install them to their own home directories, so they don't interfere with other users. The only sensible approach is one such as this, where users can only install software where they have permission to do so.
If the Fedora people really want to fix things, they could work on making their packages easy to install into the users' home folders, so users don't have to use the "configure prefix" to change things around, and then compile from source. That sort of user software installation is perfectly reasonable, and completely in line with the overarching concepts of Unix security.
Systemd: the PulseAudio of init systems
Just remove RH's key and install your own corp key then only sign tested packages. This is actually kind of cool, now you just need an easy way to make package updates mandatory like with published apps in AD.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
Pirate Party UK
My beef with this is a little different i think. While i general i dont like the idea, it goes further than that. I do not trust signed software or web-site certificates. So, just because company X uses a Verisign signature for their security of the website, or in this case signatures are given to software, i still wont trust it just because it has a signature.
This is not paranoia (i hope). Its simply because even security systems are possible to be broken.
Therefore i still would like my security blanket of having to su/sudo to do something that can affect the whole system. A kind of "stop! are you sure?". UAC made a lot of people unhappy, but it was a bold move by MS. I always hated it when applications even back in the days of Win95 would start writing to \Windows\ or \Program Files\
Still, my biggest grief with Windows is the Registry. One file gets corrupt and thats it... bye bye boot up, bye bye many of your licence keys, bye bye everything. Still, this is off-topic, but its a personal peeve of mine, and the day someone proposes something similar for Linux is the day i would switch to BSD.
Oh, yes, and that model works really well, doesn't it?
Enabling the installation of software is _precisely_ what sudo and controlled access to the "yum" command are for. Leaving this feature on by default is begging for script kiddies to slip their works into other "signed" repositories, such as RPMforge and EPEL and corporate yum repositories. Once I've gotten my GPG key into your system, I can install anything I want.
Fedora 12 is going to be blocked from my internal network until this is fixed. It can be installed in the DMZ, but will be considered an insecure and vulnerable system until then.
Yes, this sounds like a good way one can use this, but not a reason to have it enabled by default.
Just remove RH's key and install your own corp key then only sign tested packages. This is actually kind of cool, now you just need an easy way to make package updates mandatory like with published apps in AD.
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.
Things get complicated when the project's server are physically compromised. I agree that the mechanism is neat and very useful but the developers jumped the gun when they altered the default configuration without notifying anyone. This change wasn't even mentioned in the release notes. That alone raises questions about the project's development process.
Fedora prided itself with default security policy since it had SELinux enabled by default. This change is exactly in the reverse direction.
... 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.
according to Seth Vidal:
$ pklalockdown --lockdown org.freedesktop.packagekit.package-install
Ref: https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01055.html
Yes, it is most definitely insecure. This change in Fedora 12 allows an unprivileged user to:
On any normal system, the unprivileged users can do some of these things only through a *very* small subset of programs (e.g. passwd) that have been heavily vetted, and even then they still have an occasional exploit.
Now Fedora is saying "hey, all 15000 of our programs can do all of these things, and any unprivileged user can install any of the 15000 programs". Fedora has increased the number of potential exploits by several orders of magnitude.
That's insecure.
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.
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 (http://blog.internetnews.com/skerner/2009/03/red-hat-fedora-reveals-details.html), 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.