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

Comments

Of course there isn't a problem

[TSHTF]

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.

Users should not get to be root. PERIOD

[Jailbrekr]

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.

Developers vs. Sysadmins

[Anonymous Coward]

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.

Re:This makes sense

[MatanZ]

The contest might be trusted, but not wanted by the administrator of the machine.

Another way to think about it - you are now vulnerable to local root exploits not only in packages you installed, but also in packages you chose not to install.

What a mess...

[interval1066]

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.

Re:It's obvious

[644bd346996]

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.

Re:This makes sense

[Draek]

So, you argue that this is a security measure to protect systems that are already compromised with keyloggers? I... see, right... *backs away slowly*

Re:It's obvious

[bmo]

The best rant against the Windows way of doing things from Tom Christiansen:

http://slashdot.org/comments.pl?sid=3291&cid=1395315

No, I don't care that a customer asked for it. Customers are idiots, just like any other user. So what if they pay you? They're still idiots, and it's your professional responsibility to act responsibly, to refuse to go along with their madnesses. The customer is not always right. In fact, they're very often wrong. A physician or a lawyer doesn't do whatever the customer requests, and neither do you. They, meaning the customers or users, simply don't have the background and training;

Truer words were never spoken.

--
BMO

Re:This makes sense

[jmorris42]

> Another way to think about it - you are now vulnerable to local root exploits not only
> in packages you installed, but also in packages you chose not to install.

DING! You nailed it. The attack surface has been expanded to include every package in every enabled repo. Find a local root exploit in any one of them and you get the machine.

This is totally stupid. It makes the assumption that every user is an admin, which was exactly the idiocy we have, rightly, laughed at Microsoft for years over. Microsoft has been working at correcting that mistake while we have been adopting it. And it isn't just Fedora, this apparently came from upstream at PackgeKit so unless this gets nipped in the bud it will spread to everyone else.

The root of the problem is that decisions that impact security are being made by marketing people more concerned with the 'year of the Linux desktop'. And again, wasn't this exactly what we slagged Microsoft over in the past? As Linux nears readiness for mass consumption we find ourselves making exactly the same mistakes for exactly the same reasons. We are tossing decades of hard won security knowledge onto the altar of user friendliness.

We didn't learn anything. We are doomed.

Re:It's obvious

[edittard]

On Windows, only admins can install.

So only 99% of users?

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[blueg3]

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

Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY

[RAMMS EIN]

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.