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 makes sense (Score:3, Insightful)
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.
Of course there isn't a problem (Score:5, Insightful)
Re:This makes sense (Score:3, Insightful)
Re:It's obvious (Score:4, Insightful)
Users should not get to be root. PERIOD (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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 does this solve? (Score:3, Insightful)
Re:This makes sense (Score:3, Insightful)
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.
Signed doesn't mean bug-proof. Everything a user installs is just one more attack vector.
What a mess... (Score:5, Insightful)
Re:This makes sense (Score:1, Insightful)
If Ubuntu extended this right to every user who was in the admin group then I would have no problem whatsoever. It's just a question of not having to provide your password. FC providing it to all users? Easy DDOS, just install lots of stuff. Or what if they install SSHD on a machine that shouldn't have SSHD running? I bet the package sets it to start in all runlevels by default, meaning that users have the ability to open up huge security holes. Imagine a user thinking "I have an old version of package X that has a security hole, but I can install it since it's signed, and therefore gain r00t!"
Terrible idea, just terrible.
Re:It's obvious (Score:5, Insightful)
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 (Score:5, Insightful)
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:Of course there isn't a problem (Score:1, Insightful)
Worse than that, consider your same scenario where Package X suffers a critical vulnerability, but the sysadmin is on top of it so checks the system to make sure package X is not installed. Then the next day, random user or malicious user, installs package X without the sysadmin knowing.
Re:Users should not get to be root. PERIOD (Score:3, Insightful)
That is irrelevent. I suspect that a vast majority of Fedora users use standard non root accounts, and only use root for doing system maintenance or installing packages. To allow a non root user to in essence do root commands without prompting for a password just begs to be exploited. the risks that this default setup exposes far outweigh any benefits that may be gained. Is it really that hard to prepend your command with sudo?
Re:YAY!!!! (Score:2, Insightful)
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.
Re:Users should not get to be root. PERIOD (Score:3, Insightful)
Re:It's obvious (Score:5, Insightful)
The best rant against the Windows way of doing things from Tom Christiansen:
http://slashdot.org/comments.pl?sid=3291&cid=1395315 [slashdot.org]
Truer words were never spoken.
--
BMO
Re:This makes sense (Score:4, Insightful)
No, there is a significant difference between "running as Admin" and "installing a signed application without requiring root (Linux's Admin) authority".
The amount of authority granted depends on how many signing authorities you have decided to trust. If you trust only a server under your own control, for example, this could be really useful within an organization to allow users to install company-authorized packages without having to run around and install everything for everyone, while still preventing average users from doing anything to the machine.
I don't agree with this change in RedHat, but it is (fortunately) a policy change and not a programming change. In other words, it's easy for any machine owner to change the policy (which can, by the way, only be done as root) and require that all software installs be done by root only (which was the old default). In my opinion, this default should be changed back, and those people who want to send signed packages out within their organizations can change the policy.
A regular RedHat user still cannot do things like reformat the hard drive, change operating system files or core system configurations, access any data but their own, etc. Similar to a "Limited" user account in Windows (but the difference is that Microsoft, by default, has traditionally made all accounts Admin, and a lot of software vendors have come to depend on that so making a Limited user is an exercise in deep frustration in Windows).
Re:This makes sense (Score:5, Insightful)
> 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:Glad to see... (Score:1, Insightful)
Now we just wait to see how long it takes someone to digitally sign a rootkit!
Re:This makes sense (Score:3, Insightful)
And installing random stuff is an easy way to destabalise a system.
What... I want to install kubuntu-desktop on this ubuntu-desktop machine. (Yes, I know the issue is in Fedora, but the same principle applies.)
Re:This makes sense (Score:1, Insightful)
Re:Of course there isn't a problem (Score:2, Insightful)
Ah, ok. That wasn't clear to me from the description.
So you're saying that a regular luser can install packages AS ROOT without needing to provide the root password, be a member of a specific group, etc etc? And thus, a regular, otherwise unprivileged user can write to directories normally only accessible to root, install suid root binaries, and overwrite configuration files?
Wow.
Just wow.
And nobody raised a big stink about it before the official release.
Incredible.
Re:This makes sense (Score:4, Insightful)
Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY (Score:3, Insightful)
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?
Re:It's obvious (Score:5, Insightful)
So only 99% of users?
Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Re:This makes sense (Score:3, Insightful)
So giving malware which runs with user privileges a possibility to automaticaly request the installation of a package with known root exploit makes sense for home/personal use?
Re:100 posts is nothing! (Score:3, Insightful)
Re:It's obvious (Score:4, Insightful)
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.
Forget vulnerabilities, think telnetd (Score:3, Insightful)
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!
Re:This makes sense (Score:2, Insightful)
B) If there's already malware on the machine running as the user, there's not much benefit to getting root access anyway. It can log the user's activies, steal info, make connections to remote servers just fine with the user's privileges.
Re:It's obvious (Score:3, Insightful)
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.
Re:It's obvious (Score:2, Insightful)
The best rant against the Windows way of doing things from Tom Christiansen:
http://slashdot.org/comments.pl?sid=3291&cid=1395315 [slashdot.org]
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.
Re:This makes sense (Score:3, Insightful)
A) What's to stop a user from providing the root password if malware attempts to install something?
At least there is still a possibility for the user to say: "Oops, I didn't intend this!" Where as in the automatic installation this is not the case.
B) If there's already malware on the machine running as the user, there's not much benefit to getting root access anyway. It can log the user's activies, steal info, make connections to remote servers just fine with the user's privileges.
There is still a chance that the main system does not get infected. There is still a chance that the malware will not be executed when the user logs in again. And it is easier to clean the system if only the user data is compromised.
If the attacker gains root acces your only way to ensure that the system is 100% clean is to reinstall it from scratch.
Re:It's obvious (Score:1, Insightful)
Re:This makes sense (Score:3, Insightful)
That's the thing. Every time you see a comparison of security in Windows and Linux, the users in Windows is always assumed to be the administrator, and you get all this FUD about how insecure Windows is. The proper comparison would be to a Windows machine where the user is logged in as a limited user. In that case, it's as secure as a Linux box.
What utter bullshit.
First: Any comparison concerning security is misleading. I don't care if I'm just as secure as X; I only care whether I'm secure enough for a given use case.
Second: Any attempt to compare conceptual levels of security between two different platforms, in which one is responsible for the overwhelming majority of all malware infections and the other is widely understood to be effectively malware-free... well, such a comparison is disingenuous at best.
And lest anyone respond with how vulnerable Linux would be just as soon as X, Y or Z transpires, let me just say that Linux is safe now, today. If it proves to be unsafe in the future, I'll take appropriate action. Until then, theoretical threats are not nearly enough to make me prefer a platform that's theoretically equivalent but in practical terms is orders of magnitude worse.
HTH, HAND
Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY (Score:3, Insightful)
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.
Re:This makes sense (Score:3, Insightful)
The attack surface has been expanded
That was my first instinct as well, but if you look a bit more at the issue it's not much of an expansion. The possible extra surface would be suid binaries, as the ability to install and run programs is rarely secured anyway, only the ability to do it 'the right way' (ie, via package manager into the base system) is secured.
Personally I tend to be more concerned with server systems where this would not be an appropriate default policy (altho package-kit seems to offer some nice granularity in its config), but for end-user desktop systems it might even be appropriate as long as there is a reasonable selection of repositories specified. Even in an enterprise setting it could be appropriate if you think 'customized enterprise repositories' instead of 'random internet repo'.
I'll grump with the best of 'em, but some of the seemingly heinous violations of unixy traditions we've seen in the last few years aren't necessarily completely without thought. But they do require some annoying relearning before one can thoroughly criticize them on a better basis than pure instinct and after doing a cursory examination of package-kit I figure I probably need to rtfm some more before I decide what to do with it.
PackageKit at fault, not Fedora (Score:2, Insightful)
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.
Time to leave Fedora... (Score:3, Insightful)
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)
Re:This makes sense (Score:3, Insightful)
The idea of UAC is fine, but the implementation, at least in Vista, leaves a lot to be desired. The most annoying thing about UAC is that a lot of things that you need to authenticate to do also have a confirmation dialog in the application. So you end up being asked if you want to do something, clicking yes, then being asked if you want UAC to allow the application to do that. It almost seems like MS didn't actually test their software with UAC switched on.
Re:It's obvious (Score:3, Insightful)
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.
Re:sounds good to me (Score:4, Insightful)
Should you trust signed software? (Score:2, Insightful)
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.
Re:sounds good to me (Score:3, Insightful)
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.
Re:sounds good to me (Score:3, Insightful)
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.
Re:It's obvious (Score:3, Insightful)
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.
Re:Interesting comment on Bugzilla... (Score:2, Insightful)
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