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."
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.
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".'
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.
And yet when Microsoft included UAC in Windows Vista to address this very complaint they only got lambasted by you same Linux people. What hypocrisy.
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
Now we just wait to see how long it takes someone to digitally sign a rootkit!
Either that, or someone able to fool the checks for console ownership (one of the points in the email thread were that the checks weren't sufficiently robust for their comfort).
Every package from the project is signed. It doesn't 'lose' its signature just because a new rpm exists in the world somewhere that fixes a vulnerability. So a system that doesn't want to run 'extremeliabilityd' and opts not to install it at all, could be compromised anyway.
Why would one want to imitate the Windows 95 model for deployment security?
XML is like violence. If it doesn't solve the problem, use more.
So only 99% of users?
At the bottom of the
Yes, only the console user can install packages.
Or, any software the console user is running?
Or, perhaps, a web page that the console user is viewing through a web browser with a security vulnerability that enables remote code execution?
Or, perhaps, an ad embedded in a web page that...
You are right that the idea is that this only applies to the scenario where there is, essentially, a single user who owns, operates, and physically sits at the PC, and that a lot of people seem to be missing that.
However, if you own, operate, and physically sit at your PC, how onerous would it be to have to enter your password, or even the root password, when you want to do something as disruptive and uncommon as use the package manager to make system wide changes?
And if that is indeed too onerous, how bad would it be to have to change the configuration to allow you to do same without having to enter a password?
In either of those cases, you would have a secure-by-default design. Deviating from that just opens a huge can of worms (no pun intended), as there are suddenly a lot more things you need to worry about - and failing to worry about them gives you an insecure system.
Doing something as unexpected and potentially dangerous as this should NOT have been done without ample discussion, and should definitely have been mentioned in the release notes and during the installation procedure - probably with an option right there to turn it on and off, and probably with the default being off.
The mind boggling WTF here isn't that somebody thought letting users install packages without having to enter a password is a good idea, but rather that the new, disruptive, less secure setting has been made the default without the world, the users, or even the developers knowing about it.
Please correct me if I got my facts wrong.
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!
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.
It is necessarily insecure: At any point in time there can exist signed software in the repo which the user can install and which has known exploitable vulnerabilities. Therefore it follows that malicious code running as the user can, without root privileges, install said software and then exploit the vulnerability automatically and without the users knowledge. Its just a matter of effort to create a virus/worm that quarries for current unlatched packages and exploits them or runs in the user context again until such time as it can. Once root the policy is exploited once the policy can be used again by adding a malicious, but now trusted repo so the user code can keep getting root and reinfecting in the future as needed. This is a path to turn a malicious unprivileged user exploit into a system exploit, not unlike the many IE cross-zone security problems of the past.
I've got a box sitting right here, I'd love to see you boot from a LiveCD. Not real sure how you're going to do it considering the CD isn't part of the boot sequence and the BIOS is locked with a password.
You could try to move the drive to a new machine if you'd like, but since thats going to require you digging it out from behind a table, with several large items sitting on top of it, I'm probably going to notice you doing it. Did I mention the case also has a lock on it?
I let plenty of random people use it, its a shared workstation in a hotel for guests to use.
Now, with that in mind, how safe does it sound now?
This is a retarded policy choice no matter how you look at it by a couple of douce bag milkshakes who shouldn't be allowed to commit to any repository on the planet, even their on personal one.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
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.
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.
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.
Greetings.
The two comments you quote have been posted by the developer that appears to have made the change in the first place. In his blog, he also explains how that is part of the "philosophy" of the application, and somesuch.
It is also of interest that other developers on the same thread appear to be on a similar short fuse (see comment #144). There is a very annoying tendency (on the bug coments and the ML) to simply tell people who argue against this behavior to either add more justifications (as if they were actaully needed) until they are blue in the face or to shut up (or, sometimes, just the latest).
It has basically turned into an ideological war, and it's ugly to behold.
Cheers,
alf