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."
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?
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:This makes sense (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:This makes sense (Score:3, Interesting)
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:User-level package manager (Score:2, Interesting)
Autopackage.
Great for developers of programs, but from what I can tell, useless if I want to install something that someone wrote, which usually use the autotools.
Applications have to be modified to specifically support $HOME installation (or, to be more exact, installation to arbitrary locations), and most Unix apps right now don't support this without hardcoding paths during compilation time.
That's fine... whatever. I'd be perfectly happy with something like a userland emerge that compiled everything on demand.
Re:Of course there isn't a problem (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.
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.
Re:What does this solve? (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 not on the "approved" list and therefore in the repository require root access.
However, this configuration setting was still a Bad Move on RedHat's part. If a corporation wants to allow this, they'll probably also want to think about the list of signing authorities they want to use. So this should be OFF by default and if an administrator wants to turn it ON they'd need to take action (and would presumably know what they are doing and why).
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.
Re:This makes sense (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 multi-megabyte graphical horror. :)
Of course if you can prevent the machine from downloading the updated package lists you could probably trick it.
Easy way to disable...? (Score:3, Interesting)
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: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:This makes sense (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:It's obvious (Score:2, Interesting)
Honest question: Do RPM files have a way of distinguishing between system- and user-level software? It seems like a fairly obvious thing to have/check, then users could install safe applications (i.e. those that don't have programs in /sbin or /usr/sbin), for their own uses.
Moreover, why can't RPMs just let users install in a private fakeroot directory (like there home directory). That way they don't have to touch the root file system and can easily install packages without needing a password. (Like if I wanted Eclipse, I could just find the RPM and double click to install it, no password, no fuss.)
I think Fedora could make this right if they wanted to.
Re:Should you trust signed software? (Score:2, Interesting)
Damn, why is there no edit button? I wanted to give an example of how things can be faked that are meant to be secure.
Many years ago (student days, in the UK) i recieved some spam (physical mail) but not addressed to me. And this gave me an idea. Back in those days passports were only needed for travel and not much else. For example, to get a bank account you could get away with just presenting two utility bills. So, i decided to start collecting 'evidence' that my name was actually the name from the spam mail. Now it was safe to presume this person actually had lived at my address previously, and therefore some corroborating evidence already existed. I therefore registered myself as a new name to go on the utility bills, got a library card, and got the local council to send me council tax bills in my new name (i claimed that "i" had left this address, and a new tenant had moved in... they never checked with the landlord... after all, somebody was giving them money, and nobody would give them money if they didn't have to. Next up was a bank account. "No, sorry, i dont drive, and i dont have a passport, but i have these two utility bills". Within a couple of months i had a very well documented and valid ID that even the police wouldnt question unless they did some real digging. The only thing i didnt go for was a passport, and this was because a) would have required some real forgery work, and b) probably could have ended up in a lot of trouble.
As an interesting PS, you would not believe how many credit cards i got offered in my new name. I even applied and received one but tempted as i was i never used it and in the end just threw it away to get rid of the temptation.
So... do you think you should trust digital signatures if i can create a fake identity? I'm a lot less clever than some of the people out there.
Re:This makes sense (Score:2, Interesting)
package conflicts? (Score:1, Interesting)
I don't like this one bit.
What about package conflicts? If 2 packages conflict with each other, a regular user can remove the conflicting package? Doesn't look like a sensible thing to do....
not only can some idiot install random packages from the repo, but also remove certain 'needed' packages.
This is disturbing indeed.
Re:It's obvious (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.