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."
Wow (Score:5, Funny)
Sounds like I need to upgrade to Windows 7 for some real security...
You laugh, but.... (Score:5, Funny)
Re:You laugh, but.... (Score:5, Informative)
They're in for a long battle.
Considering that the fix to this is already written out in one line of code in the same thread on the same day here:
https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01055.html [redhat.com]
And they have already admitted that the default security setting is not consistent with the philosophy they had built the Linux system on in the past. That's a pretty good turn around time for a mistake in the security area of an OS.
Re:Wow (Score:5, Funny)
I'm not even sure who to ROOT for anymore.
Haha, that was so terrible, please don't mod me funny.
Re:Wow (Score:5, Funny)
I, unlike you, feel no shame.
Re: (Score:3, Informative)
You need the package to have a signature that is already registered. Fedora 12, like early Fedora releases, doesn't register _any_ GPG keys for RPM until after manual authentication by the user. "yum install" asks for this during software installation. Unfortunately, many sites that deal with signed packages don't protect their signatures well, and it's dificult to tell which signatures for RPM are installed or appropriate. So it's a vector, just not as bad of one as you note.
Glad to see... (Score:5, Funny)
whatcouldpossiblygowrong? (Score:2)
Just hope that your appliance manufacturer has disabled this.
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.
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
No, its a fail. Any OS vendor / Linux distro which thinks this is a good idea needs whacking hard with a two-by-four till they get the message that this a fail whoever does it.
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
The thing is that Linux does not require the root password to do everything. The commonest task that requires it is installing software.
From what I understood of the complaints about Vista, it required the root password a lot more than Linux does.
Re:This makes sense (Score:5, Interesting)
Sudo doesn't take your root password, it takes your password. Also, I'm not aware that anybody with a clue has complained about UAC whilst cheering about sudo. UAC is actually a step up from sudo because it uses a secure input driver to stop a programme clicking OK automatically whereas with sudo there's no equivalent protection from keyloggers.
The only real advantage of sudo over UAC is that you can user sudoers to limit which executables normal users can run whereas with UAC you either have admin rights for everything or nothing, although I suspect you can mess around with user rights in Windows to give much finer grained capability permission.
The only issue with UAC is how annoying the prompts can be and that's because of badly written software that assumes it has to have full admin rights. UAC prompts happen less these days though.
So yea, at least check the facts before posting. Must troll harder!
Re: (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: (Score:3, Funny)
Re: (Score:3, Interesting)
I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. This significantly limits the number of users with powers to install signed software -- almost to the point of where it sounds like a fair trade-off. If someone has physical access to the machine, then heck -- it's not like they don't already effectively "own" it. Not saying it's a good default policy -- but let's cool our heads. Regards,
So these is really a real world access security vulnerability in which case there are several easier ways to do damage.
Not that I agree with this default of course, it still allows idiots (girlfriends, who am I kidding this is slashdot, your mum) to install crap all over your system.
Re: (Score:2)
Re: (Score:2)
Microsoft lets you install unsigned code as well.
Without being admin/having to go through the UAC thing?
Re: (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 vulnera
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)
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.
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: (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 so
Re: (Score:3, Interesting)
> I wonder if they handle replay attacks?
Under normal conditions it wouldn't work. Yum won't allow unpriviledged users to install things, those guys aren't idiots. This is a hook into the command line that triggers if you type the name of a command that isn't installed. So it would only grab the most recent version it knew of.
And anyway, when did making the command line user friendly become such a big push, I though we were supposed to consider any use of the command line a bug to be fixed by an new m
Re: (Score:3, Informative)
Ah contraire. If you read the mailing list you will see that one of the idiots supporting this madness is Seth Vidal, the lead developer and maintainer of Yum.
Re:This makes sense (Score:4, Informative)
> Wow the FUD flies fast and furious here.
> I doubt very much that most Fedora installs even have an administrator, or serve more than a home user.
So many words from someone who can't read. And they said write only devices were mythical. :)
As stated in my post avove, this isn't so much a change in Fedora as a case of Fedora being the first release with this new policykit. If this isn't stopped, flamed into oblivion, shouted down, whatever, it will end up in Ubuntu, Debian, Suse, eventually everything down to FreeBSD because this *Kit crap is infecting everybody. Or it will be individually patched out by individual package maintainers and we all know that is sub-optimal.
And yes even Fedora has users. Even if you are correct that few corporate types will be rolling F12 out to end users there are things called families. I admin my home machine but I'm not the only user. No I don't trust every person I give an account to enough to allow them to have admin rights. Remember trust in the sysadmin sense is more about trust in their skills/knowledge not whether you would loan em a hundred bux.
Re: (Score:3, Informative)
Re: (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.
Re: (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:5, Informative)
No, it does NOT make sense. It creates a new security risk: If some malicious software (runing under with normal user privileges) notices that a hackable software is missing on the computer (one which has a known security vulnerability to gain root access) it can now install this package without problem and gain root access later on.
A sudo approach like done in Ubuntu is much better.
Re:This makes sense (Score:4, Insightful)
Re: (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: (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: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:This makes sense (Score:5, Funny)
User-level package manager (Score:4, Interesting)
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?
Re: (Score:3, Funny)
Re: (Score:3, Informative)
http://github.com/mxcl/homebrew/ [github.com]
It would probably not be much of a challenge to make that work on a Linux machine. That and a Linux tool for this probably already exists.
Re: (Score:2)
Stow isn't quite what you want, but it's pretty close. I've used it for just about ten years for locally-compiled stuff.
Generally what I do is ./configure --prefix=/usr/local/stow/[PACKAGENAME-VERSION] && make && sudo make install, then cd /usr/local/stow and type "sudo stow [PACKAGENAME-VERSION]. Removal is a simple cd /usr/local/stow && sudo stow -D [PACKAGENAME-VERSION]. It doesn't worry about dependencies at all, and really all it does is make symlinks in /usr/local/bin, /usr/
Re: (Score:3, Funny)
You can make emerge to install stuff anywhere, don't forget to add yourself to the portage group.
Too bad this isn't Gentoo and I don't have root on it.
Re: (Score:3, Informative)
One of my friends has even more stuff installed locally than I do; he gave GoboLinux a try a while (few months?) ago but found the rootless mode "fragile:"
(4:38:11 PM) me: what were your objections to gobolinux's package manager? remember?
(4:38:36 PM) him: oh
(4:38:53 PM) him: The environment it set up was really fragile
(4:39:00 PM) him: I broke it several times
(4:39:09 PM) me: environment variables you mean?
(4:39:11 PM) him: Lots of the pkg config stuff didn't end up being found properly
(4:39:29 PM) him: ye
Of course there isn't a problem (Score:5, Insightful)
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, somethin
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
The thing that I would ask here is whether the user can install a specified older version of a given package. Say, for instance, install the original version from the main repository with a know vulnerability that is patched in the update repo.
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.
Re: (Score:3, Informative)
RH didn't give any go ahead, it was the PackageKit upstream that did it without any communication.
Also:
NO documentation about this 'feature'.
Terrible configuration system.
Also, the entire mailing list had to do their own homework about this policy.
Re: (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: (Score:3, Insightful)
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: (Score:3, Funny)
Science is vulgar compared to mathematics.
I bet you're even one of those dirty experimentalists, or even worse, a chemist!
Re:Developers vs. Sysadmins (Score:4, Informative)
- Richard Feynman
Re:Developers vs. Sysadmins (Score:4, Interesting)
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).
We did okay in our office. We let the dev's admin their own machines and an actual sysadmin, like yourself, run the production environment. For the desktops users put in an install request and we installed the software for them. It wasn't that hard, we didn't get a lot of requests.
I don't see the conflict myself. Just by running CentOS dev machines and Ubuntu for commodity desktops, we were light years ahead on security without even doing a lot. As long as no one is staying logged in as root, there are much easier targets. It's kind of like the bear joke. We don't have to have bear proof security, just better security than the company next door.
Re:Developers vs. Sysadmins (Score:5, Funny)
Thank goodness for virtualization. I can keep the host system locked down and fairly pristine, yet inside the virtual environment I am a wild man with wild thoughts, eating my oatmeal without a spoon, cutting off mattress tags, and installing beta code wherever I see fit.
What does this solve? (Score:3, Insightful)
Re: (Score:3, Interesting)
It depends on your environment. For an individual user, you'd want sudo or su and you'd want to be prompted for each install. And that's a good thing.
But in a large corporate environment, I might want to make a bank of internal applications available (similar to Microsoft's "Run Advertised Programs"). I could configure all of my corporate desktops to only recognize the signing authority of a repository I own, then any of my users can install anything they want off that repository. But installs of things
What a mess... (Score:5, Insightful)
Potential worm exploit (Score:5, Interesting)
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.
Re: (Score:3, Funny)
YAY!!!! (Score:5, Funny)
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!
Re: (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:YAY!!!! (Score:4, Informative)
Yes, because as everyone knows, whenever ANYONE speaks about Linux, it's the SAME person who made another previous statement about Linux.
UAC is an excellent attempt at a Windows implementation a proper security model (temporary escalation of authority for a specific task, with prompting). Personally my only complaint about UAC was that it took Microsoft so long to finally come around to something like it. I run XP as a limited user, and it's very frustrating to see all the software that has been written for Windows that assumes you are running as Admin simply because that's the Windows XP default.
And, yes, I'm clearly and keenly aware that Microsoft is not responsible in any way for the laziness or incompetence of third party developers who write code that runs on their OS. But it does point back to the whole issue that's plagued Microsoft all along - security was ignored for way too long in Redmond, and continued as an oft-ignored afterthought well after they had gained a reputation for writing insecure code. I will give them credit - once they finally extracted cranium from anus and got the clue meter off zero, they made a relatively impressive turnaround in security in a very respectable amount of time.
Require Password Instructions (Score:5, Informative)
Hmm... (Score:4, Informative)
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.
LOCAL USER ONLY, AND SIGNED PACKAGE ONLY (Score:3, Informative)
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.
Re: (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 dep
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: (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
One way to root a Fedora install (Score:3, Interesting)
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.
Interesting comment on Bugzilla... (Score:3, Interesting)
Interesting and wrong [redhat.com], 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. [redhat.com] Sigh.
Line crossed.. (Score:4, Informative)
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.
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)
It is an irony... (Score:3, Informative)
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.
It's Official... (Score:3, Informative)
... 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.
Re: (Score:3, Informative)
Or you could install RHEL
That is what they want, apparently:
https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00945.html [redhat.com]
"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?"
Re:It's obvious (Score:4, Insightful)
Re: (Score:2)
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: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.
Re: (Score:3, Informative)
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.
Re: (Score:3, Interesting)
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 [redhat.com]. 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.
Re: (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: (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
Re: (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 F
Re: (Score:3, Informative)
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...
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:It's obvious (Score:5, Insightful)
So only 99% of users?
Easy way to disable...? (Score:3, Interesting)
Re: (Score:3, Informative)
A more 'correct' way to disable would probably be something like what's described here [wordpress.com].
Editing the package-kit rules also seems to make it possible to obtain some finer granularity that doesn't seem as unpalatable as sometimes inappropriate general install rights.
the way to disable this (Score:3, Informative)
according to Seth Vidal:
$ pklalockdown --lockdown org.freedesktop.packagekit.package-install
Ref: https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01055.html [redhat.com]
Re: (Score:3, Insightful)
Re:sounds good to me (Score:5, Interesting)
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.
Re:sounds good to me (Score:4, Insightful)
Re: (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: (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 i
Re: (Score:3, Informative)
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.
Re: (Score:3, Informative)
System - Administration - Add/Remote Software
Games - [x] abe
Apply
Installed abe (Scrolling, platform-jumping, ancient pyramid exploring game) without any password at all on F12 (not user, nor root). It was not installed in the user directory, it was installed the same as if "yum install abe" was executed by root, solving dependencies as well.
I see others discussing how to solve this via polkit. Another solution for my multi-user systems where non-admins shouldn't be mucking around, I see the simple fix as
Re: (Score:3, Informative)
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.