Slashdot Mirror
Fedora 12 Lets Users Install Signed Packages, Sans Root Privileges
eqisow writes "The new default policy for Fedora 12 allows local, unprivileged users to install signed packages without root access. This change apparently went mostly unnoticed until after the Fedora 12 GA release, at which point it sparked a mailing list thread that is, as of this writing, over 100 posts long."
Oopsie?
Shiny. Let's be bad guys.
Sounds like I need to upgrade to Windows 7 for some real security...
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
They're just trying to make it more like Windows.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
...all those laid off Microsoft employees already found work.
Just hope that your appliance manufacturer has disabled this.
thegodmovie.com - watch it
If the content is trusted then requiring the user to get root privileges is just a security risk (key-loggers). I do hope, however, that they had to foresight to require specific permissions to allow users to install signed packages. I don't want my guest users installing every signed package and filling my HDD.
What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever && make install' but without the complete bitchness of dependency hell -- without any root privileges at all. Anyone know of one?
Certainly there can't be a problem here, says the Fedora team. According to the release notes, there are 15,000 packages which can be installed by these unprivileged users. That's a lot of fscking code -- surely some of it is poorly written. Consider this scenario: Package X suffers a critical {local, remote} root vulnerability. If the vulnerability isn't public, any local user (and maybe remote ones too!) has root. If the vulnerability is public, there is often a long window between downstream fixes and Fedora fixes. In either case, this is a security issue. The Fedora team really should have put this in the release notes and reconsider this implementation in the first place.
That is just silly. Users are users for a reason, and admins are admins for a reason. If users want to install software, they can use sudo.
Whoever approved that in the Fedora team needs a refresher in security.
Feed the need: Digitaladdiction.net
Ah yes, the age-old struggle between developers and sysadmins bears yet more sour fruit.
After working as a sysadmin for 10+ years for several groups of Linux software devs, I realized that devs don't make good sysadmins, and vice-versa (in general).
Developer workstations are usually a mess of tweaks, customizations, hacks, extraneous libraries that they were "testing" three months ago, odd daemons, and all kinds of other crap. They would install new packages hourly - so all the better if they could do it without requiring root access to the servers.
Sysadmins on the other hand tend to be uptight control freaks who micro-manage every little thing. This is great when we're talking the company webservers, but when it comes to developer workstations, well... the devs weren't too happy about being locked down.
I guarantee you that this feature was requested/suggested by one or more developers on the team, who thought it'd make their lives easier. And I also guarantee you that most of the people against it are system administrators.
God, I'm glad I went back into Science.
I really don't understand the basis for this move. From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine. Its seemless in Linux and OSX. Not prompting for authentication for signed package installs is insanely insecure and borderline insane.
The email trail even includes a query from a redhat developer asking why its such an issue. Incredible. I was going to quote some of that thread but the entire exchange is pretty funny, odd, and scary. Remind me to continue to not use RH, at least as a server.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Suppose someone wrote a worm that could get access to the system as a user. Then all they need is to find a signed package with a privilege-escalation bug, and whether it's installed or not, the malware could exploit it, gaining root access.
But apart from that, I can see where this would be nice from a single-user system standpoint.
Does it uses SELinux in any way? So that only a handful of users are able to install signed rpm packages?
errera hunamum ets
This smells of a back door to me.
I'm going back to Slack!!!
oh wait.
I never left. /me smugly picks up tobacco pipe, and takes a few puffs...
Fedora, Now With The Power Of Windows!!!!
Tired of those pesky admin privileges. Tired of using superuser. Want everyone on your system to install what they like, even from websites that say "Install Me!", why Fedora 12 is here! Come on, don't be afraid. Flush forty years of basic security principles down the toilet!
The world's burning. Moped Jesus spotted on I50. Details at 11.
This change only applies to Fedora's desktop oriented spins, not the server versions, and it makes sense from an usability point of view. No user should be able to gain root access just by installing a signed package from a signed repository. It might be possible, but since Fedora controls all of those packages it should be easy to prevent that possibility. Overall, I think the increase in usability outweighs the security concern and definitely outweighs the argument of "expected unix behavior". This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.
If it *is* a desktop scenario, then controlling it via sudo shouldn't be a problem. If you don't have sudo access, I don't see why you should get to install packages...
Second, a vulnerability is found in an apache package in fedora 12, and the repo is fixed, but vulnerable versions from release may be had by crackers. A fedora server with multiple users that doesn't happen to have apache installed is vulnerable to having the vulnerable package injected by an untrusted user.
XML is like violence. If it doesn't solve the problem, use more.
Browsed through the list. Here are instructions to require a password for signed repo. I agree with many of the mailing list users, this is a very bad default and there seems to be an assumption of targeting the desktop, or single user environments...
Trying to install linux on my microwave, but keep getting a kernel panic...
I'm not sure that this is a good default setting(though I would say that it is much more defensible for a desktop oriented distro, with the ability to turn it off; while it would be unsuitable for a server/corporate lockdown box setup). However, aside from the on by default/off by default question, I don't really understand what the big deal is.
Some people are freaking out, as though context-sensitive privilege escalation is some sort of ghastly betrayal of all that is UNIX and Good(tm). That seems frankly nonsensical.For example, good old Sudo does exactly that. If you are on the sudoers list, you can do some or all things as a different user(usually root) with just your own credentials. This is wildly useful, and is a routine part of a great many UNIX systems. In desktopish contexts, we've also had things like automounters for external storage, doing a limited amount of trusted stuff as root, for some years now. Not necessarily the thing for servers; but usually good for desktops.
I don't know whether this is a good default or not, and I'd certainly want to see it mentioned in the docs(assuming it isn't already, haven't checked). However, limited privilege escalation mechanisms, for performing a set of trusted actions, have been part of UNIX for years. Anybody who is merely blowing up about that, rather than about the defaults question, is being reactionary in a way that isn't even accurate.
Mandriva had a function like this called rurpmi. (r as in "restricted") that would allow sudoers allowed only rurpmi to install (Signed) packages. I'm not sure if this is exactly the same thing.
but I don't know if it is. It makes sense for my computers when I am the admin and my three other users are friends and family. It does not make sense for computers where I have worked. Of course they used CENTOS or RHEL. Which I would have blithely updated before admins had a clue to say don't do that. It would have made reversion a nightmare. It might have fixed some problems but I don't know how many new problems it would have introduced. This does seem to be headed towards the Windows model of security which maybe a great strength for Windows but it is also its greatest weakness.
MS is hit hard because they have had similar bad ideas, combined with having hired bad developers (and getting worse). But MS is now focused on Security, and is slowly making progress. I fear that if and when they surpass *nix (Linux, BSD, OSX, and some of the smaller ones like Solaris :) ) in security, that *nix will suddenly be slammed with virus and worms. And it will appear to happen overnight, even though it will be possible openings like this that slowly turn the heads of the writers.
I prefer the "u" in honour as it seems to be missing these days.
This smells like a back door.
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.
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.
Banu
.. the ./ community, or on the mailing list thread. Bets anyone?
"at which point it sparked a mailing list thread that is, as of this writing, over 100 posts long."
Pfft. 100 posts is nothing. Consider your audience; this is slashdot!
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
They had to do this in response to Microsoft patenting SUDO.
Interesting and wrong, 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. Sigh.
Go somewhere random
As long as the program never runs with privileges different than the user installing it then it's not really a concern. In fact, it's not really any different to the user running whatever software they want in their home directory. However, as pointed out by many before, if the program runs with elevated privileges or under a different username or even worse, as root, than it becomes far too dangerous to allow. Hopefully a sane compromise can be achieved like only requiring root privileges to install programs that run elevated.
The big security issues are with services and suid/sgid binaries. As long as installing the package doesn't cause any other users to run that code it shouldn't be any more of a problem than letting the user run their own code. Those probably should require root to install.
This isn't 100% watertight but would drastically reduce the scope for local root exploits.
It'd be stupid to have this policy on a server, obviously, but it doesn't seem to be that absurd at all for desktops/workstations.
This can theoretically be easily disabled by chmod'ing to everything under /etc/yum.repos.d as 600, and of course making sure that everything there is owned by root. Assuming this doesn't extend to rpm, and my initial tests suggest it may not, then that should be enough to lock it down for the most part. This is preferable to locking down the yum binary since a user could just bring their own binary to the system and then install at will. I'm sure my method could be bypassed but I haven't had a lot of time to test so someone else feel free to test it.
0x09F911029D74E35BD84156C5635688C0
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!
After reading the list discussion I can only say...
Thank fucking christ for Debian. The illogical "security" ideas of some involved with Fedora is shameful.
I've been using Fedora for years now. This has been available at least for the release cycle of F11 (possibly F10). The main difference is the implication that this is the default. Since Fedora 10, you only needed to authenticate as root once. After this, that user is able to install anything without having to re-authenticate.
For those with gnome, try the command polkit-gnome-authorization. From this the default required authorisation requirement can be set. For F11, the default is Active Console: Admin Authentication (keep indefinitely). Presumably this has been set to Authentication (ie, user auth) or Yes in Fedora 12. Change this as appropriate.
I will agree though, if this is the default, then this is a frankly bad decision. If the computer is single user, that user would have the root password and, as said earlier, would have already authenticated.
Besides the obvious problems with this that I've already seen posted here... Couldn't a user install everything from an approved repo and crash the machine by filling up all the disk space? Seems like an attack vector for denial of service attacks.
Geeks like to think that they can ignore politics, you can leave politics alone, but politics won't leave you alone.-rms
Isn't this just a separation of root binaries/local binaries, I mean if the packages are signed and placed in a users dir and the user can not install unsigned apps. Then I seen don’t really see a problem with this. It might increase the attack vector a little bit.
But I could see this helping in a corporate environment. Admin could deploy a standard set of apps, and the different department would deploy there own, Then the user could use his own personal email and browser that best fits with there workflow.
I will properly stick with the Debian/Ubuntu way, but I an not blankly ruling this out as a deployment method until I know more about the pros and cons.
I think the reaction is a bit over the top
OMG!!!! my box will get pwned
I will give the Fedora devs a chance and run this in a virtual machine for testing.
Its the same with all operating systems what are the default policies for the systems?
Why do you think there is 1001 flavours of linux no one distro, Will fit all ways of administration.
this basically means "I allow you to install any package which I have signed. You don't need to log in as a more-powerful user to do so, because I have already pre-approved this action, just as if I added the specific command to the sudoers file with no password"
The default signature is that of redhat, but there's no reason to expect the same technique couldn't be used for other signatures. Sounds like a good idea, especially for a corporate environment (single deployment, but if some people need to install Eclipse, they don't need to contact support to do so)
The next step along the line is to tie this into the existing "that command doesn't exist, install Foo to use it", to turn that into "Foo isn't installed, do you want to install it?" and a (sorry) windows-style "how recently was this used?"/auto-remove-during-updates and make the whole operating system feel entirely seamless in terms of application usage.
This is a good thing.
-- 'The' Lord and Master Bitman On High, Master Of All
Here's a blog post on how to disable it: polkit and package kit and changing settings
I might be getting a bit conservative in my old age but what of what is explained in that post is better than visudo?
There's an easier way...
It's a good idea but it's also something that is both unexpected and in many situations undesirable. Therefore IMO it is not something that should be done without warning the person doing the install.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I undestood locality to console as an 'authentication' scheme for reboot/shutdown -h now. That is a transient state change with, in theory, no lasting effects on the underlying platform. The slight risk of temporary DoS is taken understanding that the user would otherwise resort to ungraceful use of the power button.
I understand the use for removable media, where the owner of auto-plugged media is assigned to the 'console' user. Persistent state change is possible, but restricted in scope to a removable device that someone at a 'console' controlled physically anyway.
However, this is a mechanism that allows a user to make persistent state changes to the 'root' owned content. This is simply not acceptable. The act of installing software is rare enough so the password shouldn't be considered horrible, and no worse alternatives are likely if a user cannot install the software conveniently.
XML is like violence. If it doesn't solve the problem, use more.
This sounds like a bad idea in a corporate environment, where hot-desking is king. The last thing that corporate support want to deal with is random people completely changing the configuration of the machine so stuff doesn't work right (different versions, slightly different locations / configurations / yadda yadda) for the next user.
Maybe if this policy allowed non-system software to be installed chrooted to the user it would be useful. Maybe. But here, Red Hat is fixing something that simply isn't broken.
Those in the know about packagekit just uninstall it as one of the first tasks after installing fedora.
Most fedora people prefer good old yum instead.
It has been said time and time again by more than just the fedora community that packagekit is crapware and that fedora should drop it.
The message just doesn't seem to be getting through.
It comes as absolutely no surprise what so ever that the problem stems from packagekit.
Knowing how many really bad bugs there are in fedora 12 having tested it since alpha, it might be a good idea for potential adopters to wait for the fedora 13 released spring next year, instead.
I can then go to any fedora 12 desktop (say, an entire college lab), and install that package to exploit, to get root.
That is brain damage.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
This discussion has lost touch with reality. People are panicking and, with limbs flailing wildly, denouncing RedHat and exclaiming that poor, innocent sysadmins will be unarmed against RedHat's monstrous, security-jeopardizing onslaught. RedHat's decision is moronic as any reasonable person should agree. But let's regain some reality here: every competent sysadmin will simply change the PolicyKit settings:
polkit-action --set-defaults-any org.freedesktop.packagekit.package-install auth_admin_one_shot
Notice how many commands that requires? One. This changed default will affect few users' systems and certainly won't affect mine.
(Fedora and Ubuntu also provide a GUI to change PolicyKit settings.)
I could be mistaken but I reinstalled F12beta after a major disk crash, and I had to auth once to ConsoleKit, which memorized my authorization for my current user. You don't have to memorize the auth, in which case you have to type the root password each time ... or did I miss something?
I can understand not wanting this for new packages, but for updates to packages already installed, this strikes me as better than the Ubuntu way.
There is one security advantage for the average user, it limits the number of times you have to type the damn password, therefore avoiding the numbing down and making trojan type attacks more noticeable. IE if a fake popup asks your for your root password you might not pay attention if you've been asked a thousand times already for something as mundane as updating.
Lots of posters flying off the handle that obviously didn't read the actual thread. PackageKit added this as a "feature" without notifying the Fedora team. yum still behaves as expected. I'm assuming that PackageKit still requires root to modify shared system areas where the owner is root (e.g. /usr/bin etc.), but users can install their own local packages using PackageKit.
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.
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)
For every problem, there is at least one solution that is simple, neat, and wrong.
I was doing it for years on Slackware and it was one of my biggest gripes with package management.
I used to do stuff like download an xmodem protocol app, compile it and run it as a binary from my home directory. There's no reason I shouldn't be able to install OpenOffice in ~/bin/Openoffice instead of /usr/bin/... except that package managers don't work for non-root users.
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.
As long as it is an option, and turned off by default.....and who has to sign these packages?
Curious about Storage and Virtualization? Check out
But NO ONE talks about how do you really tell if your Linux Machine is actually compromised! And what to do if you are!
Yes there is chkrootkit , Sectool ( which appears to have lost all steam ) and / or screwing around with some packet analyzer like Wireshark, but the fact remains IF YOU ARE INFECTED ON A LINUX MACHINE CHANCES ARE YOU WILL NEVER KNOW ABOUT IT! And if you somehow find you are infected, what to do... install the whole damn system again? Please believe me... I am in no way pushing Windows. But at least on windows , there are virus/malware detection and removal tools.
It's not whether or not Red Hats decision will invite such things as keyloggers, but Linux's incredible lack of infrastructure to detect and remove them.
And that my friends is the elephant in the room.
"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 [...] 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 proper way to "pre-approve" a package installation in a corporate environment is having it already installed, not raising privileges. If there's a need for a user to work with superuser privileges you give him root password for the box.
"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?""
You know Debian allowed this for ages (auto-apt, but of course you need superuser privileges), don't you?
I will not be downloading another fedora until this is fixed.
This is utterly wrong.
I can self sign a package myself in a minute, does that count?
Who installs eclipse? The pre-compiled binaries work just fine :P
Just remove RH's key and install your own corp key then only sign tested packages. This is actually kind of cool, now you just need an easy way to make package updates mandatory like with published apps in AD.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
What about ongoing maintenance and modular base images? We've had that on Windows since forever where we can publish applications to a user and allow them to install in on first run without requiring administrator access.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I believe that they removed the one-time auth and replaced it with no auth whatsoever, hence the brouhaha.
"It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
A lot of people here have pointed out the vulnerability of allowing someone to choose to install a package with a known exploit, but even if no such buggy code existed, there are other vulnerabilities to consider. For example, if regular users install a signed package of wireshark and/or metasploit they can now use such tools to attempt to compromise network security.
this wouldn't make sence even if all that code was audited - which it isn't.
It was a nice surprise to get references to man pages - I had thought linux folk had forgoten all about them.
this is "Drop-Trow" security - I can't deploy it - what the hell happened to Fedora this past year, Fubar is not a stategic objective.
back to Slackware I guess. at least the sound works.
How does something like this differ practically from using sudo, which in many distros grants the user root privileges without any further authentication necessary?
These "freedom" goons always do things like these for devious political intents and poor young adolescents fall for the "freedom" thing and get infected...
I cannot believe the Fedora team has actually made such a big change and one of the first instinctive explanations is
I don't particularly care how UNIX has always worked. Looking at the use-cases and the things people are trying to do this seemed the best default. Admins can trivially change the default on machines if they wish.
Don't you guys have enough work fixing bugs and security vulnerabilities in the core packages?
Don't those guys at security firms all over the world get income from testing open source programs and publishing vulnerabilities?
What happens to them if all signed packages were secure by default?
Is that a wise assumption?
What's wrong with "remember authentication"?
Politics. That's the only explanation I can think of. Distro Level Trolling !
They are upping the usability factor which is good. The difficult part, which windows has worked on for years, is blending usability along with that security.
Its not so easy to do eh Linux?
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.
There are some differences, but many of this is already possible. You just have to download source, compile it and install it a place where you have write access.
So for people wanting to exploit bugs, this is a non issue.
Of course, i'd like packages running with root permissions to be excluded from this.
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.
What you need is a complete filesystem lay-over for the specific user. Then it doesn't matter that a user has installed a certain package. It's just that the other users won't be able to see it.
Religion is what happens when nature strikes and groupthink goes wrong.
Get several packages blessed, sanctified, anointed and kissed by David the inbred developer with every flaw, buffer overflow, gimme-root command, system-wipe command I can just to show I care.
I'll wrap at least one into a turkey punching game as a nod to the zombie apocalypse.
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.
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.
Summary 1/ It's a good idea, really good actually & very useful - YAY 2/ It comes switched on by default which might not be ideal in all situations - BOO 3/ But don't worry, it doesn't leave your machines wide open in any way - YAY 4/ It's one line to switch it off: - DOUBLE YAY pkalalockdown --lockdown org.freedesktop.pakagekit.package-install Conclusion: 4:1 YAY:BOO ratio
we are all cosmic nuclear waste
Training users to type in their password whenever they need to install software is a usability problem that leads to a security problem of users typing in their password in order to install a trojan with elevated permissions.
Yes, this is a really good point. The most secure system is the one that asks the user least; the more questions you ask them, the less attention they'll pay to them, and so the less security-conscious their responses are likely to be.
... 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.
according to Seth Vidal:
$ pklalockdown --lockdown org.freedesktop.packagekit.package-install
Ref: https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01055.html
I'm just glad Fedora got this mistake out of the way already. If this is truly a default setting in upstream PackageKit then the next LTS of Ubuntu might have suffered the same mistake. With all this stink, however, I imagine it will not be duplicated in other distros.
How are you going to slip something into a signed package?!? That's the whole point in signing it, it can't be tampered with or the signature becomes invalid.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Has anyone else noticed French words such as sans gradually creeping into English in place of perfectly good words such as without? I believe that this is not coincidental but rather the work of a dedicated group of French extremists who, by gradually increasing the proportion of French words in circulation, hope to replace the English language entirely within just a few decades. Par recognizer this behaviour, we can arret it before it gets out of main. Mai, si nous do not faites attention then pendant just a few ans, we could find qui French is the nouvel Anglais. Dit "non" maintenant a English avec Francais!
Diese Anmerkung ist auch auf Deutsch vorhanden.
Well it's lunch time and all the blinkenlights are working...
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.
The user can elevate, but any random code running under that user's account can't.
Unless the "any random code" is a Trojan horse that promises dancing bunnies if the user installs it.
It's specifically designed in such a way as to prevent any attempt to interact with it in an automatic fashion
Another Trojan horse program would be disguised as an accessibility tool to make it easier for users with disabilities to interact with the computer.
Read the first link. There's about 1000 people basically arguing that "if any one Fedora-signed package is compromised, then all default-install systems can be compromised by unprivileged users."
Then read comments by Richard Hughes.
It's like having an argument with someone who believes in god.
-- I was raised on the command line, bitch
Step 1: Install Ubuntu Karmic
Step 2: Log in as admin
Step 3: Create an unprivileged user
Step 4: Use user switching and log in the unprivileged user
Step 5: Log out this user and enjoy being switched back to your admin user's desktop automatically.
Now, to be fair, this is an upgrade from Jaunty, which I think may have even been intrepid before that. So perhaps this wouldn't happen in a fresh install. I currently have the problem though.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
If they allow Linux users to install packages easily, the next thing you know everybody will be using Linux.
"... Red Hat is now hiring idiot developers who don't know the first thing about UNIX."
Of course some Linux knowledge might be helpful too.
"Yes, because as everyone knows, whenever ANYONE speaks about Linux, it's the SAME person who made another previous statement about Linux."
No, but they're often thinking the same thing.
What are you doing around here?
Lord, you are missing the point entirely. There's no convenient way of turning this feature off, and it's on by default.
All that has to happen is someone decides to install 'bobs vulnerable suid package' from the fedora repository and they've rooted the machine. This is a huge step away from a secure system.
Not to mention that most competent admins have segregated partitioning and all it takes is one trigger happy user to install every package in the repository, DoS the hdd and disable the logging.
No, this isn't a Good Thing(tm) for anyone other than someone who doesn't understand what packages they want or need and so decides to randomly install everything rather than taking the time to understand.
Well, an enterprise can choose to enable allowing installation sans password of signed packages... not necessary to be a default.
And the command not found tie in is already available in F12
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
"We've had that on Windows since forever where we can publish applications to a user and allow them to install in on first run without requiring administrator access."
That's because Windows need it due to two historic circumnstances:
1) Lack of tools for properly remotely manage systems (so basically the "install on first run" was a way for the IT guy not having to go physically to the user's system to install it). That's not the case anymore
2) The registry which makes that a simple software installation requering local tweaking on the binary blob called registry
On environments that
1) Are properly and easily remotelly managed
2) Doesn't need to pollute the local system in order to run a program
you don't need that (NFS and the automounter is all you need to allow users "to install the program on first use" on UNIX and Unix-like systems on a corporate environment).
Cool, NFS and automount works great for a workstation or server with a very fast LAN connection to the NFS server, now how do you provide that same service to a road warrior?
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
"How are you going to slip something into a signed package?!? That's the whole point in signing it, it can't be tampered with or the signature becomes invalid."
But what do you exactly sign?
All you sign is that a certain piece of code is the very untampered one a given provider did release. Does signature provides a "fit for usage" meaning? Does it provide a "for your eyes only" security?
The most simple case: Take a DHCP daemon properly signed by Red Hat or even by your local authority. That's the real code, pristine and untampered just as the very signing process is meant to procure. Now, what happens when two or more instances of that very blessed piece of code happen to run out of control in the same network segment?
"Cool, NFS and automount works great for a workstation or server with a very fast LAN connection to the NFS server, now how do you provide that same service to a road warrior?"
AFS or gasp! a corporate laptop with all corporate sofware already installed.
Like many of the posters so far, I don't like users having the ability to install packages either. While there's exceptions, "users" are generally people who don't have the skills to do the administrative tasks on the system. If they have the skills, then they should have root (or sudo) access, plain and simple. Why? Dependencies. Virtually anything that someone would want to install has dependencies. Admins know about dependencies, and understand the risks associated with making changes to them. So Joe User grabs the latest and greatest music app and wants it installed, so he installs it- along with it's 3 dependencies, one of which complains that library ld.so.1 will be replaced and is needed by some other installed program. Joe User just wants his music player, so he overrides the install and forces it to overwrite the library and redirect the related links to the new library. One or more apps are now cratered because of a failed dependency. The admin now has to go through and rectify a library that was there at one point, but is now gone because of a user. Anything that has potential to change the functionality of the system should not be in the hands of a non-privileged user.
Important note: the policy in question will be changed, likely with an update to be issued tomorrow. The new policy will be more restrictive than that in Fedora 11 (it will require root authentication for each package installation operation). Please see the official announcement and the more extensive fedora-devel-list post for more details. Thanks.
This is a good thing.
Really? ... again:
Consider the consequences of this happening
Now imagine an admin had performed a dist-style upgrade from Fedora 11 to 12 (install the F12 "release" RPM, then "yum update"), without knowing about this default change to his systems' security, because it would never have occurred to him that Fedora/RH could make such an incredible policy decision. A few days later the Fedora/RH servers are hacked (again), but this time they're not so lucky. Meanwhile, user "blogs" on the admin's network is told (by PackageKit) there are important security updates available, so he decides (without any malice) to go ahead and apply the updates. Thanks to this new "security" policy, he is able to do so, but unknown to him, he's just rooted the system, thanks to the injection of a modified (and re-signed) malicious package on the hacked Fedora/RH server. This malicious package begins by deactivating SELinux (root privileges), then proceeds to delivering it's malware payload across the entire system, and (depending on what's visible to the host) the rest of the network (perhaps also by E-mail).
Now you might think this would have happened anyway, even if it had been the admin who'd performed the update, but there are a few important differences:
Even on a single-user system, Fedora's new Windows-style (in)security policy is dangerous, counter-productive, and frankly insane.
This is definitely not a good thing.