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