Book Reviews
Recent reviews from Slashdot readers:
- Advanced Excel for Scientific Data Analysis Learn to turn Excel into something that rivals Mathematica using VBA, brains, and a heaping helping of fortitude.(Jack Herrington's review.)
- Nagios 3 Enterprise Network Monitoring A great book for anyone using Nagios as more than a casual user.(jgoguen's review.)
- Schneier on Security Schneier argues that security is not something you can buy; it is something you must get.(Ben Rothke's review.)
Submitting a review for consideration is easy; please first read Slashdot's book review guidelines. Updated: 2008114 by samzenpus
7104908
story
Comments: 502 +- Linux: Fedora 12 Lets Users Install Signed Packages, Sans Root Privileges on Wednesday November 18, @04:30PM
background: url(//a.fsdn.com/sd/topics/topicredhat.gif); width:60px; height:53px;
redhat
background: url(//a.fsdn.com/sd/topics/topicsecurity.gif); width:59px; height:78px;
security
background: url(//a.fsdn.com/sd/topics/topicunix.gif); width:80px; height:57px;
unix
background: url(//a.fsdn.com/sd/topics/topiclinux.gif); width:60px; height:70px;
linux
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."
Related Stories
Fedora 12 Released 236 comments
Fedora 12 Package Installation Policy Tightened 172 comments
Ubuntu 10.04 Alpha 2 vs. Early Fedora 13 Benchmarks 157 comments
It is sweet to let the mind unbend on occasion.
-- Quintus Horatius Flaccus (Horace)
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.
Wow (Score:5, Funny)
Sounds like I need to upgrade to Windows 7 for some real security...
You laugh, but.... (Score:5, Funny)
Parent
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.
Parent
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.
Parent
Re:Wow (Score:5, Funny)
I, unlike you, feel no shame.
Parent
Glad to see... (Score:5, Funny)
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: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!
Parent
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).
Parent
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.
Parent
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.
Parent
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.
Parent
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: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.
Parent
Re:This makes sense (Score:4, Insightful)
Parent
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*
Parent
Re:This makes sense (Score:5, Funny)
Parent
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.
Of course there isn't a problem (Score:5, Insightful)
Re: (Score:3, Informative)
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, 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
Parent
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.
Parent
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.
Parent
What does this solve? (Score:3, Insightful)
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.
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: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.
Parent
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.
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.
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)
Parent
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.
Parent
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.
Parent
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
Parent
Re:It's obvious (Score:5, Insightful)
So only 99% of users?
Parent
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...
Parent
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.
Parent
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.
Parent
Re:sounds good to me (Score:4, Insightful)
Parent