Fedora 12 Package Installation Policy Tightened 172
AdamWill writes "After the controversy over Fedora 12's controversial package installation authentication policy, including our discussion this week, the package maintainers have agreed that the controversial policy will be tightened to require root authentication for trusted package installation. Please see the official announcement and the development mailing list post for more details."
Finally! (Score:4, Funny)
Re:Finally! (Score:5, Funny)
I liked for the ability for users to manage my box.
Surely the users would never do anything that would harm the system in which we all exist?!?
Re: (Score:2)
Re:Finally! (Score:5, Funny)
It took like a whole 24hrs from when a story was posted on slashdot.
What are they Microsoft?
Bunch of dirty hippie linux slackers
Re: (Score:3, Insightful)
they havent fixed it yet
Re: (Score:2)
Killjoy.
Re: (Score:2)
It (or similar) has been showing up on pretty much every story I've read on here for the last few days.
Attitude (Score:5, Insightful)
Re:Attitude (Score:4, Interesting)
Nonetheless, it's not a *horrible* concept, it was just a little too loose (as I've seen it described).
I think, as an option, and if the user was within a certain group (such as sudoers/wheel/whatever - changeable by the admin, and users who have administrative access), and only signed packages were affected (no change there), I wouldn't see an issue. At that point, it's basically saying "don't require a password for sudo when installing a package trusted by trusted authority 'xyz'".
Re: (Score:2)
Really? You think the Win95 security model was a good one?
There is no such thing as a 'trusted repository', at least not in my world. The closest thing I can think of would be if Theo de raadt personally verified and signed packages. Even then, thats still a maybe, I've seen him miss plenty of bugs over the user that lead to exploits.
When you start lowering your security to less than that of Windows, and your developers working on it don't have the slightest idea of the concepts involved (they don't, I t
Re: (Score:2)
I was unaware that Windows 95 came with a file system that supported permissions, much less the ability to install software from a trusted repository
Quit being overly dramatic, you're making yourself look like a fool.
Re: (Score:2)
I'm not even sure how that's applicable...
Should I just self-wooosh?
Re: (Score:3, Insightful)
To be honest that's kind of what I've come to expect from most FOSS projects - an attitude of "we're doing this because we want to, we donate our time for free - if you don't like it, fork it and fix it, or use something else".
It's actually hard to argue with most of the time, as they really are donating their time for free...
Re: (Score:3, Interesting)
What really got me about this one was the attitude some developers had ... constantly trying to justify their correctness, despite the huge backlash from users. I feel the trust relationship is kinda broken ... but at least they finally came around and listened.
Fedora does this all the time (or at least, often enough for me to think it's all the time). Here is a couple of examples:
Re: (Score:2)
The whole "OMG THE USERS WILL HAX0R THE M
Re: (Score:2)
"(even though it took a while)"
Um. The comment on the bug report which kicked all this off - "Seems to work: but why am I not getting a root password prompt?" - is dated 2009-11-18 07:47:19 EDT. The email announcing that the policy will be tightened is dated Thu, 19 Nov 2009 21:29:19 (again ET). That's a response time of 37 hours, 42 minutes, by my count. I think you'd find that's...really quite fast. :)
That was close... (Score:2)
...the package maintainers have agreed that the controversial policy will be tightened to require root authentication for trusted package installation.
Wow. Thank goodness those guys "discovered" that allowing non-root users to do dangerous things to the OS/application stack was a bad idea and "agreed" to lock it down. We might have had some serious problems there. (roll eyes)
WTF? How on gawds green earth did this happen in the first place?
Re: (Score:2)
WTF? How on gawds green earth did this happen in the first place?
Seriously, it's not like the final release was a surprise. Non of the beta testers noticed it and thought it might be an issue?
Re: (Score:3, Informative)
Seriously, it's not like the final release was a surprise. Non of the beta testers noticed it and thought it might be an issue?
How would they? Beta packages are unsigned, and this thing only works on signed packages.
Re: (Score:2)
Not that I have a Beta to hand to check this, but you're saying that they sign Rawhide packages, but don't sign Beta packages? I find this highly unlikely, to the extent I'd guess you just made this up.
Re: (Score:2)
Not that I have a Beta to hand to check this, but you're saying that they sign Rawhide packages, but don't sign Beta packages? I find this highly unlikely, to the extent I'd guess you just made this up.
At what point did I say that they sign Rawhide packages? They don't.
Re: (Score:2)
In which case I've lost my mind and apologise. I took the first RPM from rawhide 0xFFFF-0.3.9-4.fc12.x86_64.rpm and tested to see if it was signed. It was, but this doesn't seem to be universal, so you're right, and I'm entirely wrong.
Re: (Score:3, Informative)
In which case I've lost my mind and apologise. I took the first RPM from rawhide 0xFFFF-0.3.9-4.fc12.x86_64.rpm and tested to see if it was signed. It was, but this doesn't seem to be universal, so you're right, and I'm entirely wrong.
Most packages in the current 'Rawhide' are still packages from the final F12 release, and hence signed. If you check a package with an fc13 tag - i.e. one built since F12 went out - you'll see it's not signed. There was a full package set rebuild during the F12 cycle, before the beta release, so by the time F12 Beta came out, just about every package in Rawhide had been rebuilt since F11's release, and hence was unsigned.
Re: (Score:3, Insightful)
I hope they start signing beta packages with beta keys in the future...
Re: (Score:2)
Non of the beta testers noticed it and thought it might be an issue?
Nope, because packages in the development repositories are not signed until very shortly before release. No-one testing the beta would have seen this bug, because they'd never have installed a signed package.
Non-controversial (Score:2)
Wow. Thank goodness those guys "discovered" that allowing non-root users to do dangerous things to the OS/application stack was a bad idea and "agreed" to lock it down. We might have had some serious problems there. (roll eyes) WTF? How on gawds green earth did this happen in the first place?
The use of the word "controversial" to describe the rollback to the original, more secure settings is bizarre, too. The failure here was the process and the people that must have worked to push through the weird settings that allowed everyone and their dog to install random 'signed' but unconfigured packages. That's something we'd expect from Microsoft employees, trainees, 'engineers' or 'researchers', not Red Hat staff or volunteers.
I notice that mono has shown up in the distro, too. When will manage
Re: (Score:3, Informative)
It wasn't "everyone and their dog". You basically had to be logged into the console. I confirmed that it didn't work via a normal SSH session last night, the first time I had access to a Fedora 12 machine, was confused by it, and resolved to look into it later. The announcement helped explain what I saw.
It was still a stupid move, but it explains why more people wouldn't have noticed it in beta testing: we'd have often been logged in via SSH from our desktops. The stupidity was in introducing a distinction
Non-controversial removal of misfeature (Score:2)
You basically had to be logged into the console.
Or go to the trouble of faking that. It got spotted reasonably quickly and fixed fast enough after it was spotted. That's working more or less as it should What is broken is how did such a misfeature even get in there in the first place?
Dunno man, but (Score:5, Insightful)
The whole Fedora Team's creation of and response to this issue creates very serious doubt in my mind about their ability to manage a distribution and their understanding of proper security policy. I think they've got to open up their decision making process more and learn to communicate better. An idea this bad should have been squashed 5 minutes after it was proposed instead of being allowed to actually make it into a released distribution.
At least it all shows that the community still ultimately calls the shots.
Re: (Score:2)
I actually thought they had a fairly good point after reading one of their comments [linux-archive.org] (fifth one down, Bill Nottingham, 12:23):
Out of the box, a desktop user has the ability to shut down the machine.
This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want
-- put viruses on
- hell, slap in a livecd or USB key and reinstall the box
Point being that Fedora is designed for desktop users, and because of this the default configuration already allows a non-privileged user to do far worse to the machine than install trusted software.
Re: (Score:2)
I think it is a bad direction to go in with security policy in general.
Sure, the desktop user can shutdown the machine, etc. The issue is that the default packageKit no-password setup is a recipe for non-technical users to potentially blow their own left foot off. 99% of what one would like to guard against is simply accidental damage to the system. The other issue is once you have such a passwordless system in place someone will easily find a way to exploit it. In fact its pretty easy to do and certainly a
Re: (Score:2)
the default packageKit no-password setup is a recipe for non-technical users to potentially blow their own left foot off. 99% of what one would like to guard against is simply accidental damage to the system. The other issue is once you have such a passwordless system in place someone will easily find a way to exploit it. . . . simply essentially making the default for everything "OK, do the dangerous thing" is not an answer!
I get the distinct impression you are misunderstanding the issue: They did not implement a passwordless system. All they did was make it so no password was required to install signed packages. Installing signed packages should never result in a user blowing his foot off, it should never be a "dangerous thing". The user still can't rm -rf ./pile_o_cruft/.* and wipe out the whole file system without a password.
The only way this is a bad security issue (that I can think of) is if there is a multiuser system,
Re: (Score:2)
No, I understand the scope of the issue. I think it could be a potentially more significant problem than your analysis indicates. The majority of systems aren't going to be made insecure by it, and in fact overall security of the system in terms of the possibility of insecure software being installed isn't even necessarily the primary concern. There are simply packages that one would rather not have installed on many classes of systems because they inherently degrade the security posture, for example why sh
Re: (Score:2)
The initial change was discussed in public - on the PackageKit mailing list - and implemented over a year ago. PackageKit is an upstream project, used by multiple distributions, and this change was implemented in PackageKit (although, of course, the upstream author who proposed and coded the change works for Red Hat); it's come to light in Fedora 12 because it's the first distribution to actually use a version of PackageKit ported to PolicyKit 1.
I'm curious as to how you expect an idea to be "squashed 5 min
Re: (Score:2)
Well, I don't know, but the RESULT is what most people get to judge by. The result was a pretty significant change in behavior that seems to have hit most users of FC kind of out of left field. Maybe the whole issue isn't specific to Fedora but it points out that some level of visibility of the consequences of changes, upstream or not, doesn't exist. From looking at the chatter on the mailing list it seems to me that people on the 'inside' were aware of the ramifications of the change and let it go through.
Re: (Score:2)
From looking at the chatter on the mailing list it seems to me that people on the 'inside' were aware of the ramifications of the change and let it go through.
Not really. To the best of my knowledge, the only 'inside' people who knew about this change before the bug report were Richard Hughes, David Zeuthen and possibly Matthias Clasen.
As I said, the main thing that's likely to come out of this is a better set of guidelines and review process for privilege escalation in packages. Until now it hadn't really been a big issue because little changed much in this area. Now PolicyKit is being implemented throughout the distro there's likely to be a need for a cohere
Re: (Score:2)
Cool. I'm sure a lot of people have trouble appreciating the sheer complexity of coordinating things. Managing a large software product composed of many components is always challenging, especially if they source from so many different places. I think security is just one of those hot-button issues that raises a lot of hackles. Without knowing in detail how all the different responsibilities are divided up within the whole project and how these kinds of issues get communicated it isn't easy to know how any
Re: (Score:2)
The initial change was discussed in public - on the PackageKit mailing list - and implemented over a year ago.
Let's be clear here. They discussed modifying PackageKit to allow an administrator to create such configurations. Nowhere in the entire thread did anyone mention "Oh by the way, let's also make this the default configuration for the F12 release."
Don't believe me? See for yourself. [gmane.org]
Re: (Score:2)
Re: (Score:2)
Because there should never be any discussion and the security nazis are always right (even when they're wrong and trying to apply server/workstation security concepts out of context).
Re: (Score:2)
Ah, yes, well, why not just mention Hitler and lets have the end of the whole discussion.
Actually some of us KNOW a few things about security. In a serious way. I think I'm qualified to have an opinion.
Default Deny has been proven over the years to be the wise postion to take WRT to security settings OOTB. Anyone claiming knowledge of real-world IT security who raises an objection to that position is IMHO not someone who should be in the business of deciding security policies or implementing them. You can s
Re: (Score:2)
Re: (Score:2)
Never really thought this needed changing (Score:5, Interesting)
Re: (Score:2)
Bullshit. Worms need not require a privileged user account to be effective. A process running as an unprivileged user can:
Re: (Score:2)
You have to admit, it's pretty hard to know in advance which distro you're on and which packages are going to be available, so you have to plan to try a whole pile of exploits before you find one that works. The biggest or most common vulnerabilities are usually found, fixed, and ready for update rather quickly, so the window of opportunity is smaller as well. If the attack fails, you're restricted to listening on high ports and any other potential damage is minimized.
So I'd say the fragmentation "problem
Re: (Score:2)
Maybe. But diversity isn't so important when you have one or two very popular targets. And some distributions' packages have modified version information identifying the distribution. For example, Ubuntu's Firefox build includes the distribution name and version in the user agent. Furthermore, many
Re: (Score:2)
How many security fixes do Red Hat and Novell backport to their enterprise distributions, which frequently run "old" software (relative to Ubuntu/Fedora)?
All fixes for known vulnerabilities in supported packages in supported releases. That's kind of a big part of the definition of 'support', really.
Re: (Score:2)
Yes; it was a rhetorical question. The fact that they have to do this means that vulnerabilites are often published and fixed well after the initial release of a package.
Re: (Score:2)
The first entry is not entirely true. Non-root processes are restricted from using low port numbers(1024, iirc). Also, if there's a correctly configured firewall on the machine, a non-root process is incapable of going around it.
Not that it would actually prevent any malware I know of from wreaking havoc, high port numbers are perfectly fine for sending email and talking to bot herders.
Re: (Score:2)
I wasn't concerned about listening, actually, just outgoing connections.
How many desktop Linux users have firewalls that prevent untrusted processes from making outgoing TCP connections?
Re: (Score:2)
Non-root processes are restricted from using low port numbers(1024, iirc).
And? Just because SMTP servers traditionally listen on port 25 doesn't mean that my zombie mailer process has to; similarly clients making outgoing connections all use high-numbered ports anyway, whether they're malicious or not.
if there's a correctly configured firewall on the machine, a non-root process is incapable of going around it
Not entirely true - you can make a connection out to a known address, and have the controller on the
Re: (Score:2)
So for a general purpose machine, that needs to be able to do email, web, etc, how do you lock down connections out?
There's nothing to stop me from running my bot control software so that it is listening to port 80. Are you suggesting that I need to apply for permission to make outgoing connections to port 80 on a site-by-site basis?
You can make it more difficult for processes to dial out, but on a machine that can actually use the network, you can't make it impossible.
Re: (Score:2)
That's true, and that's my point. It is the contents of user accounts that users care about. The difference between "a worm stealing all of a user's personal information, leading to identity theft" and "a worm stealing all of a user's personal information and breaking the operating system" isn't that significant after the user's per
Re: (Score:2)
I agree with you completely that requiring root or sudo access is a good thing but the beauty of Unix and Linux is that I can install software without root privileges rather easily. Whether I extract a tarball into a fakeroot directory in my home dir or specify the same with rpm (or an rpmmacros file), it's usually trivial to install packages. What's not so trivial is to change the configuration of the host system. And I agree with you completely that requiring root or sudo access is a good thing.
This mea
Re: (Score:2)
Non-root users can't install in Windows either.
This isn't true, Windows software can copied to your user directory and run with no elevation prompt. (Google Chrome installs this way for example). You can easily test this by putting an EXE on your desktop.
The real issue is that the multi-user Admin versus User security dichotomy falls apart when the user is also the system's administrator. If you have a system where end users can install software, you can't prevent them from installing malware.
At the risk of being flamed to hell (Score:2)
The idea of allowing normal users to install signed software is actually not all that bad.
Frankly, the most common alternatives - either users have to ask IT to do it (which neither the users like nor does the IT department necessarily want to spend its days messing around with) or giving them local admin (or, this being Linux, local root) privileges are both awful.
Off the top of my head, I can think of a few sane solutions to the problem - none of which appear to have been given serious thought:
1. Provide
Re: (Score:2)
It is a horrible horrible horrible default. Provide the capability so those infrastructures that really want it can make an *informed* choice to do so, fine.
You don't have to give people *full* root privileges, you can selectively give them access through sudo to use a package installer that only works with signed packages. Though fedora emphasizes 'su' style privilege escalation which has no granularity, 'sudo' style gives the granularity required. The credential of 'oh, I happen to be at the 'local' sc
Re: (Score:2)
Though fedora emphasizes 'su' style privilege escalation which has no granularity, 'sudo' style gives the granularity required.
Um. You didn't research this very thoroughly, did you?
The whole basis for the introduction of this issue is the use of PolicyKit, which is massively more flexible and fine-grained than su *or* sudo. Both su or sudo can only run entire processes as a different UID, and have fairly limited authentication method choices. PolicyKit allows far more fine-grained granting of escalated privileges; that's the whole point of using it in PackageKit, the main PackageKit GUI process runs as an unprivileged user and P
Re:At the risk of being flamed to hell (Score:5, Informative)
This is just nonsense, TOTAL NONSENSE.
Unix users have ALWAYS had the ability to install applications into their own home directory. Ok, so it (maybe) never occured to the authors of Linux package managers to target the users home directory. However, the fact remains that the ability/possibility has always been there. You simply don't need to pollute the system files in order to "install an app" on Unix. That is one of it's key strengths.
This is why the Fedora guys got skewered.
Some of us have been "installing applications" in our home directories since before the first line of Linux was written.
Re: (Score:2)
This is by far the best comment in here.
Thank you for thinking outside that tiny box of a coming-from-windows mindset, that so many “new” people wrapped themselves in in the last years.
The saying “Those who do not learn the history, are doomed to reimplement it. Badly.” fits perfectly here.
It’s the same set of people who work so hard, so make KDE and Gnome virtually indistinguishable from the incredibly primitive UI of Windows. (In case you don’t know: Everything that sti
Re: (Score:2)
I have one word for software which can be installed without root privelege:
ActiveX
Re: (Score:2)
I'll dive in burn with you on this one. You missed one other major point that the Fedora developers had. A large majority of their user base is desktop systems where there is not some great IT staff or distant administrator. I am the admin in my boxes. No one else has a login. If I want to install packages without a password that shouldn't be difficult. I configured the repositories, I added the public keys after evaluating how much I trusted the repo. Letting the normal user (still me) install packa
KPackageKit (Score:2)
I have a similar complaint about KPackageKit. You can optionally choose to make it store your password so that you don't have to type it in when you next install or update packages. That's fair enough, if you trust that no one is going to install anything dodgy then that's OK. What I do take issue with is that this box is checked by default.
Granted I imagine most people might simply click this anyway but am I the only one who thinks this is a bit of an oversight?
Re: (Score:2)
Bad security should not be the default.
The reason is simple. If users know what they are doing and give due consideration to security, things are fine either way. You can enable whatever insecure settings you want, and I can't stop you, and it's good that way. You can also tighten the security of your system to the extreme, and I won't be able to stop you, and it's good that way. It's your system, you can do as you please.
Now, if users don't know what they're doing or don't give due consideration to securit
Outrageous (Score:3, Funny)
TROLL:
Allowing users to conveniently install signed/authorized packages/software.This is LINUX dammit if you're not jumping through hoops to get something done you are DOING IT WRONG!.
RANT:
Non-root users will destroy EVERYTHING that's why they must be frustrated for the sake of SECURITY. That white-listed signed software package must be personally allowed by the head of IT before installation can complete!
QUOTE:
If you give up freedom for security you deserve neither - Thomas Jefferson -
SENSIBLE RESPONSE:
Fedora caved in to a knee-jerk reaction. The compromise should of been allowing admin's to white-list a subset of the signed packages that they want to allow all users unrestricted access to. The year of unnecessary security is upon us.
Re: (Score:2)
"The compromise should of been allowing admin's to white-list a subset of the signed packages that they want to allow all users unrestricted access to."
if the admin's going to go to all the trouble of whitelisting a subset of signed packages, why not just...install them? It's not like disk space is expensive. Also, I don't know a lot of admins who would welcome the prospect of trying to evaluate a list of around 10,000 packages as a great way to spend their weekend...
Re: (Score:2)
If the distro provided white-list groups then it could be useful. E.g. the groups "non server apps" "non setuid apps" "server apps" "setuid apps". A cautious admin might whitelist the intersection of the first two, while more laid-back admins could enable them all.
Re: (Score:2)
Wow, that about covers it. WAY TO GO BUDDY... now I have to go back to work.
Re: (Score:2)
You got the gist of the quote but the original is much better. And it came from Ben Franklin.
To quote Richard Hughes: (Score:4, Informative)
To quote Richard Hughes, the developer responsible for the braindeadness in the first place, and repeatedly trying to brag his competency of being a dickhead in the bugzilla(https://bugzilla.redhat.com/show_bug.cgi?id=534047 [redhat.com]).:
Source: http://blogs.gnome.org/hughsie/2009/09/23/linux-is-about-choice/ [gnome.org]
It seems that he interpreted his own words as "Just because you can do something, doesn’t mean you should do it. But for me, I can fucking make whatever 'choice' and screw everybody else. Bwahahaha!"
And his recent rants:
(Source: http://blogs.gnome.org/hughsie/2009/11/20/the-fedora-12-installing-saga/ [gnome.org])
But he was the one who was being a troll first. Quotes from the bugzilla:
Now, I'm wondering how on earth did someone got a job for being a devtroll. Red Hat pays him to develop, but trolling the bugzilla? I don't remember anyone "attacking him personally" on the bugzilla. I wasn't following the mailing lists though.
And he now seemed hurt because the users actually bothered to donate their own time correcting his mistake.
Grow up.
Almost sounds like Ulrich Drepper (Score:2)
"You missed the "in my opinion" line in your reply." [and others]
Heh... I half expected to see Ulrich Drepper's name in the bug discussion (famous for his glibc controversy regarding support for those fishy "Carp Architectures").
None of that real trolling then, I see ;-)
Re: (Score:2, Insightful)
* "It's not insecure. We've had the mechanism checked. The default policy may not be to your taste, but this is the "desktop" spin, not the "server" spin. " (Fedora = Desktop, RHEL/CentOS = Server)
* "You either trust the Fedora repos or you don't." (This is true. Either you trust Fedoraproject to keep malicious packages out of the repos, or you do not. Therefore, a trust of the default repos wouldn't be so bad)
* "I don't particularly care how UNI
Re: (Score:2)
Re: (Score:3, Insightful)
I don't see how most of those quote could be considered trolling, but especially this:
# "There are other, *easier*, ways of rooting the system. "
That's totally accurate. The policy previously allowed users who were logged in to the local console to install signed packages from a repository. No one would claim that there are no security vulnerabilities in packages within the default repositories, but they tend to be fixed very quickly after they are found, so the window for exploit using this mechanism is extremely small. People do have legitimate reasons why the
Re: (Score:3, Informative)
The policy previously allowed users who were logged in to the local console to install signed packages from a repository. ... Users who have physical access to a computer can compromise it far more easily than waiting for a vulnerability to be found in a package that isn't installed, installing that package before an update is issued, and exploiting the vulnerability.
You are incorrect in equating local console logins with physical access. I pointed this out several times on the bugzilla, but it seems that the myth persists.
There exist OS-level tools such as x11vnc or x0rfbserver whose entire purpose is to provide remote users with the ability to manipulate the local console. These tools do not require root privileges to run. An attacker who gains remote access illicitly can compile or copy over an x11vnc binary and subvert the local console.
Of course, an attacker w
And the announcement got it wrong (Score:3, Informative)
Notice that the announcement said:
> The update will require local console users to enter the root password to install new software
packages.
This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.
This is the sort of linguistic sloppiness that lead to the shrieking by users. While such inconsistent behavior for the console versus logged in SSH users has no reasonable excuse and shouldn't have happened, the danger was much less than the early explanations lead reasonable people like me to believe, because many of the discussions left out the "this only works from the console" part. And given that the new Fedora release is taking a bit of time to download, we hadn't had the chance to try this ourselves.
Re: (Score:2)
> This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.
Obviously wrong? How are they going to use sudo if it isn't configured by default. This is Fedora not Ubuntu
Re: (Score:2)
Exactly, if we are including custom configurations into our logic, they could just revert this fix entirely, nullifying the entire story!
Re: (Score:2)
This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.
kpackagekit is for those who doesn't install software from the command prompt but prefer a "click-and-drool" interface, so 'sudo' isn't an option.
Besides that, 'sudo' has a very coarse security model, you can either install all kinds of software with 'sudo yum/apt/rpm etc' or nothing at all. kpackagekit allows for a much finer and more secure model, like only allowing the user to install
Re: (Score:2)
The announcement is correct. PackageKit requires the root password, not the user's own, to add or update packages from the local console.
Re: (Score:2)
This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.
No. PackageKit will still use PolicyKit. The change is that it will now require "auth_admin", which does indeed require the input of the root password. (This is like sudo configured with the rootpw flag in sudoers.)
It would also be possible to configure PolicyKit to require "auth_self" (or auth_self_keep, which remembers that you authenticated for a few minutes), which would provide sudo-like behavior. But that wasn't done.
So the announcement is right.
Arguably, the current (i.e., old again) behavior isn't r
A sensible compromise (Score:4, Insightful)
The policy of allowing certain users to install software, within certain limits, is not crazy. It gives you:
* don't have users typing in the root password all the time
* if you need a codec or viewer plugin, the system can pop up a "Getting a viewer for you" window, rather than a "Can't view this, please install foo, put root password here"
* this is made possible because Linux distros have their own "app store" of approved software, which comes *from the distro* so you know where to get it and you know it's relatively unlikely to be malware. Windows and MacOS can't do this.
The limits included only giving these privileges to the console user, who probably has physical access and can root the machine anyhow, which is also sensible. But it also gives malware the local user might end up running (e.g. due to a Firefox compromise) the ability to install software. That's not necessarily too bad unless it's, for instance, installing vulnerable setuid-root software. So this needs to be thought about carefully before enabling on an individual machine, unless the distro has thought *even harder* about it so you don't have to. It doesn't really seem like the Fedora guys thought about it hard enough, even though it could be a good policy for the future if done right. And I don't think anybody is happy about such a major change in behaviour happening without it being announced and debated very publically.
I hope to see this feature reappearing in a future Fedora release - it's a good feature if they do it right. But they should be *even more* careful about what they permit and they shouldn't make dramatic behaviour changes occurring by default without heavy debate (and if you upgrade from an old version, rather than clean install, it should certainly say "This is a behaviour change, do you want it?" - probably defaulting to no.
Re: (Score:3, Informative)
With sudo, they don't need to type the root password, they need to type their own password.
Of course, you're still able to make the system behave so that users can install software without typing in their password -- it's just not the default now.
It would be nice, though, for package managers to support user installation (to the user's home directory).
Re: (Score:2)
Yes, though I don't think Fedora configures sudo access for users by default unless things have changed? But even if I were right about that, it could at least be set up by the administrator in order to avoid giving out the root password, which is probably still a good thing (though if sudo is configured to allow a user to run any command with it then I'm not sure that protecting root's password is that beneficial?).
The minimum thing I'd want to see *by default* is probably that a user has to type in *a* p
Re: (Score:2)
Very much agreed that package managers really ought to support (by default IMO!) the ability to install to a user's homedir, whether or not that user has the ability to perform a system-wide install. I'm fed up of having to install stuff from source (without dependency management) just because I only want something in ~/.
High-level package managers generally don't expose that functionality because many packages aren't really built to expect it. In theory packages should be perfectly relocatable, but in practice most maintainers never test installing them anywhere but / , and they tend to do things based on the assumption they'll be installed to / and by a process with root privileges (for instance, updating certain databases in %post scripts wouldn't make much sense for a package being installed as a user). If you want to
Re: (Score:2)
I have had the impression that packagers generally don't provide for non-/ installations; my "really ought to support" phrase was intended to include the packagers themselves but I probably should have stated that explicitly, since that's where a chunk of the real problem probably lies.
I actually thought I remembered rpm having an ability to specify a number of allowed locations for install, so that the packager could say where they could cope with it going. I might be making that up, though, or maybe it i
Re: (Score:2)
I dunno, really, like I said, I haven't tried it :) why not play around with it in a VM - for bonus credit, in several different distros - and write up an article / blog post on the results? I'd sure find that interesting.
Re: (Score:2)
Re: (Score:2)
Only one of those requires that the user know the root password.
This is useful if you have two users that you want to have root privileges -- particularly considering that you can restrict what operations a sudo user can perform.
Tempest in a teapot (Score:2)
How many Fedora installations actually have "users" and "admins?" The line that you don't want your users installing software just doesn't hold any water. Honestly if you have an "admin" and "users" you'll be wanting to harden the install anyway, and more than likely you will not want to use Fedora. Instead you'd do CentOS 5 or Ubuntu LTS. Most installs of Fedora are on single-user, home systems. Even in a family situation, a parent will likely want to enable parental controls anyway, so creating a lim
Re: (Score:2)
Even more ironically, most of the comments seem to indicate that sudo is a recommended solution! Are you kidding? ... If a user wants to do something that needs more privileges, you grant him carte blanche root access?
That's not what sudo does, necessarily. There is a file that can be used to list the commands that a given user/group can run using sudo. If the command you're running isn't in that list (including the arguments you're supplying) then you don't get permission to run it.
It's common to allow peo
Re: (Score:2)
Yes this is true. But it's still coarse. You can restrict what binaries are run, yes. But what about things like controlling access to removable devices? Clearly sudo isn't enough. In fact in the long run PolicyKit will completely replace sudo. So sudo serves some good purposes, particularly in the realm of system administration. But let's not mistake it for a solution to the core problems of security on modern desktop systems.
Anyway, if you want to lock down Fedora for a user, you configure PolicyKi
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Do /. writers get paid by "controversy"?
I submitted the initial story, but they edited it a bit a before publication. I'm _sure_ it didn't have three 'controvers*' in it, but I can't prove it to you, I didn't keep a copy of my submission. It _was_ pretty late last night. Usually I'd shoot myself in the head before writing something that inelegant. :)
Re: (Score:3, Insightful)
What about installing finger/telnet/etc?
What about installing sendmail and conflicting with the postfix installation?
What about installing 1Gb of maps for some random game?
What about updating a package that the admin knows will generate a conflict with other in-house application? (I don't know if updates were included in the policy, but is the same criteria)
Re: (Score:2)
So redhat still plans on making this change. They are just waiting till they implement the GUI to easily change a user's role.
Well, um, then it's not going to be the *same* change, is it? The point is that you'll be able to choose what kind of role a new user account has, and hence what actions it'll be able to do. A regular, non-admin user account won't be able to install software this way.
Re: (Score:2)
Good, particularly if it defaults to requiring the root password.
For those that don't know, Fedora 11 already had an interface where administrators can change whether numerous other actions require a root password (and whether it requires it every time or just the first time.)
Extending that to include installing signed packages gives the administrator of a system the ability to choose for their system whether they trust users to install packages without contest or not.
I think the only problem with F12 was t
Re: (Score:2)
i'd be happy if they fixed the checksum file which incorrectly states the sha256 hashes are sha1.
It doesn't. It states that the signature on the CHECKSUM file is SHA-1, which it is. The file is signed with an SHA-1 signature, the checksums themselves are SHA-256. This is admittedly somewhat confusing, and will be changed to be less so in Fedora 13. But it's not incorrect.