Hello,
I find that the update utility in Fedora is not like in their previous versions I have used (at least until Fedora 20).
The system notifies that there are updates and when the user clicks ok to install the updates, it usually asks for the root or system administrator's password to authorize the update. However, it is strange to see in Fedora 22 that no such security is available.
Any normal user could easily install the updates that include kernel, X11 and all system related installs without the need for the system administrator. This might disrupt or falsify if some settings are done by the system administrator.
Is this bug going to be fixed or the Fedora community is going more toward Microsoft Windows OS like theme of installing the updates without the need for the system administrator.
I hope that this is not the future of Fedora. Fedora is unique in its way and I see that it is adopting more like Microsoft Windows display theme including menus.
Thanks
Nethaji
Why would you change this setting?
Surely this is a feature and not a bug.
On 12 May 2015 at 22:29, Thiyagarajan, Nethaji n.thiyagarajan@ucl.ac.uk wrote:
Hello,
I find that the update utility in Fedora is not like in their previous versions I have used (at least until Fedora 20).
The system notifies that there are updates and when the user clicks ok to install the updates, it usually asks for the root or system administrator's password to authorize the update. However, it is strange to see in Fedora 22 that no such security is available.
Any normal user could easily install the updates that include kernel, X11 and all system related installs without the need for the system administrator. This might disrupt or falsify if some settings are done by the system administrator.
Is this bug going to be fixed or the Fedora community is going more toward Microsoft Windows OS like theme of installing the updates without the need for the system administrator.
I hope that this is not the future of Fedora. Fedora is unique in its way and I see that it is adopting more like Microsoft Windows display theme including menus.
Thanks
Nethaji
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Tue, May 12, 2015 at 09:29:00PM +0000, Thiyagarajan, Nethaji wrote:
Any normal user could easily install the updates that include kernel, X11 and all system related installs without the need for the system administrator. This might disrupt or falsify if some settings are done by the system administrator.
Two things:
* Only official, signed packages can be installed in this way. There's no way to install a false package.
* It's not actually available to "any normal user". You are an administrative user — a member of the `wheel` group.
On Tue, 2015-05-12 at 17:47 -0400, Matthew Miller wrote:
- It's not actually available to "any normal user". You are an administrative user — a member of the `wheel` group.
To be clear: if you don't like this behavior, go to Settings -> Users, hit the Unlock button, enter your password, then change Account Type from Administrator to Standard. Note: if you don't have a root password, you must set one from the command line with 'sudo passwd' before doing this.
I always have a root account on my system and add a user after every new installation using 'useradd' command. I do not create a user at the time of installation.
The sudo command does not work on my account as the user is not in the sudoers list. The user's name is not in the wheel group either. I usually never add a sudoer to the system.
The only different thing that I did was update from Fedora 20 to 21 and to 22 whilst the account remained on the system.
There is a small shield like thing appears (in green) when updates are available and on clicking 'install the updates', it does install everything.
As a normal user I cannot install anything that would be in the root directory. The partitions in my system are '/boot', /'/, 'swap' and 'users'. So the user account is created under /users and given a normal user privileges.
To my knowledge as I mentioned above I have not added a user to sudoers list or wheel group. I do not think that updating from Fedora 20 to 21 or 22 should do this without consulting the 'root'.
I am at office now and when I go back home this evening I will check in the sudoers file whether the user's name is listed in there. And if, then it is the system update through 'fedup' that might add the user automatically to the wheel group.
Will update in the evening GMT.
Thanks Nethaji
On Tue, 2015-05-12 at 17:06 -0500, Michael Catanzaro wrote:
On Tue, 2015-05-12 at 17:47 -0400, Matthew Miller wrote:
- It's not actually available to "any normal user". You are an administrative user — a member of the `wheel` group.
To be clear: if you don't like this behavior, go to Settings -> Users, hit the Unlock button, enter your password, then change Account Type from Administrator to Standard. Note: if you don't have a root password, you must set one from the command line with 'sudo passwd' before doing this.
On Wed, 2015-05-13 at 09:33 +0100, Nethaji wrote:
I always have a root account on my system and add a user after every new installation using 'useradd' command. I do not create a user at the time of installation.
The sudo command does not work on my account as the user is not in the sudoers list. The user's name is not in the wheel group either. I usually never add a sudoer to the system.
Actually, sorry, Matthew and I were wrong. We do allow unprivileged users to run software updates (provided all of the updates are cryptographically signed by Fedora). You can configure this behavior manually by creating a file in /etc/polkit-1/rules.d with the following contents (untested, should work):
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update") { return polkit.Result.AUTH_ADMIN; } });
Then unprivileged users should no longer be able to run updates.
Hope that helps,
Michael
On Wed, May 13, 2015 at 07:49:34AM -0500, Michael Catanzaro wrote:
Actually, sorry, Matthew and I were wrong. We do allow unprivileged users to run software updates (provided all of the updates are cryptographically signed by Fedora). You can configure this behavior manually by creating a file in /etc/polkit-1/rules.d with the following contents (untested, should work):
Huh. Last time this came up in FESCo, I thought the decision was to keep the policy as it had been (passwordless updates for admin users only).
On Wed, May 13, 2015 at 9:07 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, May 13, 2015 at 07:49:34AM -0500, Michael Catanzaro wrote:
Actually, sorry, Matthew and I were wrong. We do allow unprivileged users to run software updates (provided all of the updates are cryptographically signed by Fedora). You can configure this behavior manually by creating a file in /etc/polkit-1/rules.d with the following contents (untested, should work):
Huh. Last time this came up in FESCo, I thought the decision was to keep the policy as it had been (passwordless updates for admin users only).
Yes, I agree. We really need to change it back to that if Software (or anything else) is not in compliance.
josh
Hi Michael,
Many thanks for the update and a fix. I hope that adding a rule would work.
As Matthew mentioned it will be nice to keep the policy to root or system admin only even if it is cryptographically signed by Fedora.
Thanks Nethaji
On Wed, 2015-05-13 at 09:11 -0400, Josh Boyer wrote:
On Wed, May 13, 2015 at 9:07 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, May 13, 2015 at 07:49:34AM -0500, Michael Catanzaro wrote:
Actually, sorry, Matthew and I were wrong. We do allow unprivileged users to run software updates (provided all of the updates are cryptographically signed by Fedora). You can configure this behavior manually by creating a file in /etc/polkit-1/rules.d with the following contents (untested, should work):
Huh. Last time this came up in FESCo, I thought the decision was to keep the policy as it had been (passwordless updates for admin users only).
Yes, I agree. We really need to change it back to that if Software (or anything else) is not in compliance.
josh
On Wed, May 13, 2015 at 02:30:55PM +0100, Nethaji wrote:
Hi Michael,
Many thanks for the update and a fix. I hope that adding a rule would work.
As Matthew mentioned it will be nice to keep the policy to root or system admin only even if it is cryptographically signed by Fedora.
For reference, here is the policy https://fedoraproject.org/wiki/Privilege_escalation_policy
On Wed, 2015-05-13 at 09:34 -0400, Matthew Miller wrote:
For reference, here is the policy https://fedoraproject.org/wiki/Privilege_escalation_policy
The policy prohibits unprivileged users from downgrading packages (which could undo security patches) but not from upgrading packages, except it does prohibit upgrades from one Fedora release to the next.
Still, we can be stricter than the policy requires if we want to be:
mcatanzaro: Anyway I think it's OK to require authentication to install updates, because on multiuser systems it's legit to expect the admin to install updates, and on single-user systems the user should be an admin. mcatanzaro: But: currently anaconda creates non-admin accounts by defa ult. That's bad.
halfline: mcatanzaro: man it's like you were standing here in the cubes with us halfline: you just parroted what i said in meatspace almost verbatim 5 minutes halfline: ago
So I checked with Richard Hughes and the way the rules currently works is that there is a difference between install and update. If you want to install a new piece of software you need to be part of the wheel group, but any user can update already installed software as long as it is signed Fedora software. (Well technically they are not even doing that since updates are done offline these days).
Christian
----- Original Message -----
From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, May 13, 2015 9:07:28 AM Subject: Re: Fedora 22 update security
On Wed, May 13, 2015 at 07:49:34AM -0500, Michael Catanzaro wrote:
Actually, sorry, Matthew and I were wrong. We do allow unprivileged users to run software updates (provided all of the updates are cryptographically signed by Fedora). You can configure this behavior manually by creating a file in /etc/polkit-1/rules.d with the following contents (untested, should work):
Huh. Last time this came up in FESCo, I thought the decision was to keep the policy as it had been (passwordless updates for admin users only).
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Wed, May 13, 2015 at 9:47 AM, Christian Schaller cschalle@redhat.com wrote:
So I checked with Richard Hughes and the way the rules currently works is that there is a difference between install and update. If you want to install a new piece of software you need to be part of the wheel group, but any user can update already installed software as long as it is signed Fedora software. (Well technically they are not even doing that since updates are done offline these days).
Right, but that is the problem. On a multi-user machine, allowing a non-admin user to update e.g. firefox can result in some very strange brokenness with currently running firefox instances. Also, updates can bring incompatibilities with them and should be done by an admin.
I realize the rationale above is _mostly_ covering for inadequacies in application software but that is reality today. However, even ignoring those issues, updates to core packages shouldn't be done by a non-admin user.
josh
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
Christian
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, May 13, 2015 9:53:23 AM Subject: Re: Fedora 22 update security
On Wed, May 13, 2015 at 9:47 AM, Christian Schaller cschalle@redhat.com wrote:
So I checked with Richard Hughes and the way the rules currently works is that there is a difference between install and update. If you want to install a new piece of software you need to be part of the wheel group, but any user can update already installed software as long as it is signed Fedora software. (Well technically they are not even doing that since updates are done offline these days).
Right, but that is the problem. On a multi-user machine, allowing a non-admin user to update e.g. firefox can result in some very strange brokenness with currently running firefox instances. Also, updates can bring incompatibilities with them and should be done by an admin.
I realize the rationale above is _mostly_ covering for inadequacies in application software but that is reality today. However, even ignoring those issues, updates to core packages shouldn't be done by a non-admin user.
josh
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Wed, 2015-05-13 at 09:55 -0400, Christian Schaller wrote:
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
And afaik, a user needs to be an admin to reboot (which is necessary for applying offline updates) if other users are currently logged in.
On Wed, May 13, 2015 at 9:55 AM, Christian Schaller cschalle@redhat.com wrote:
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
That seems to directly contradict what Nethaji reported to start the thread. If he was prompted for updates, and clicked apply updates and they were applied, that doesn't sound like we only do offline updates.
Perhaps someone should try and recreate this.
josh
On Wed, 2015-05-13 at 09:59 -0400, Josh Boyer wrote:
On Wed, May 13, 2015 at 9:55 AM, Christian Schaller < cschalle@redhat.com> wrote:
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
That seems to directly contradict what Nethaji reported to start the thread. If he was prompted for updates, and clicked apply updates and they were applied, that doesn't sound like we only do offline updates.
Perhaps someone should try and recreate this.
He also talked about a 'green shield', which doesn't sound like anything you would see on the workstation...
On Wed, 2015-05-13 at 09:59 -0400, Josh Boyer wrote:
That seems to directly contradict what Nethaji reported to start the thread. If he was prompted for updates, and clicked apply updates and they were applied, that doesn't sound like we only do offline updates.
Perhaps someone should try and recreate this.
josh
Nethaji is definitely not using Fedora Workstation. As Matthias pointed out, the green shield is just not something we have. He must be using some spin (perhaps the KDE spin?). (Michael reads more email. Yup, he's using the KDE spin, not Workstation.)
But anyway, from a security perspective: you can use the PackageKit D -Bus API to perform an online update without authentication, or a client like pkcon (installed by default) or GNOME Package Updater (no longer installed by default). The reboot is not enforced.
Did we forget the hardway of booting a system? Just push and hold the power button and anyone can boot it and the OS cannot control anything. Even if it is an offline update, admin cannot stop from it being applied on a reboot.
I see a green shield like thing (KDE and oxygen theme for desktop), I will take a screenshot of it when updates appear again or I can downgrade some package so that the update icon will popup to say that there is an update available.
Nethaji
On Wed, 2015-05-13 at 10:00 -0400, Bastien Nocera wrote:
----- Original Message -----
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
And only admin users can reboot the machine while other users are using it...
On Wed, May 13, 2015 at 10:00 AM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
And only admin users can reboot the machine while other users are using it...
Even in that scenario I'm don't believe allowing non-admin users to apply updates is the correct thing to do. I mean, your friend is over and turns on your laptop and logs into the non-admin account he created. He sees updates and says to apply them (via offline updates or not). He reboots the machine since he's the only logged in user. Now you have a bunch of updates applied that you didn't know about the next time you log in.
This really seems like a bad idea to me.
josh
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, May 13, 2015 10:27:23 AM Subject: Re: Fedora 22 update security
On Wed, May 13, 2015 at 10:00 AM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
And only admin users can reboot the machine while other users are using it...
Even in that scenario I'm don't believe allowing non-admin users to apply updates is the correct thing to do. I mean, your friend is over and turns on your laptop and logs into the non-admin account he created. He sees updates and says to apply them (via offline updates or not). He reboots the machine since he's the only logged in user. Now you have a bunch of updates applied that you didn't know about the next time you log in.
This really seems like a bad idea to me.
Well I guess it comes down to who we design the default install experience towards. My take is that our primary target is people on single user system with the idea being that people in more complex setups would be installing using kickstarts and similar and thus be able to tweak the configuration of such systems to suit their requirements (what tooling we offer or lack of such for helping with such tweaking is another debate).
So even in the single user scenario I can see that examples as the one you mentioned can happen, but I can't help but feel that the problem here is with your friend and not the system for assuming he should feel free to update your machine without asking you.
That said this is not a major issue to me as the default behaviour should be here that the first user created on a system should be in the wheel group (which we need to fix as this does not happen if you set up your user using Anaconda, but it is the case if you set up your user using the GNOME initial install wizard.)
Christian
On Wed, May 13, 2015 at 11:14 AM, Christian Schaller cschalle@redhat.com wrote:
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, May 13, 2015 10:27:23 AM Subject: Re: Fedora 22 update security
On Wed, May 13, 2015 at 10:00 AM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
And only admin users can reboot the machine while other users are using it...
Even in that scenario I'm don't believe allowing non-admin users to apply updates is the correct thing to do. I mean, your friend is over and turns on your laptop and logs into the non-admin account he created. He sees updates and says to apply them (via offline updates or not). He reboots the machine since he's the only logged in user. Now you have a bunch of updates applied that you didn't know about the next time you log in.
This really seems like a bad idea to me.
Well I guess it comes down to who we design the default install experience towards. My take is that our primary target is people on single user system with the idea being that people in more complex setups would be installing using kickstarts and similar and thus be able to tweak the configuration of such systems to suit their requirements (what tooling we offer or lack of such for helping with such tweaking is another debate).
So even in the single user scenario I can see that examples as the one you mentioned can happen, but I can't help but feel that the problem here is with your friend and not the system for assuming he should feel free to update your machine without asking you.
We're going to have to disagree then. The problem isn't with a friend. If the system allows a user with 0 privileges on the system to potentially majorly change the system, it's a problem with the system. I could come up with other scenarios involving kids using a shared family laptop and terrible analogies about loaded guns with no safety, but I'm trying to avoid hyperbole.
That said this is not a major issue to me as the default behaviour should be here that the first user created on a system should be in the wheel group (which we need to fix as this does not happen if you set up your user using Anaconda, but it is the case if you set up your user using the GNOME initial install wizard.)
Sure, the default cases are all covered and mostly unimpacted because the first user should be an admin. I agree. What I disagree with is saying that is good enough and leaving the non-admin user hole around. Put another way, changing the policy to prevent non-admin users from applying updates does not impact the default Workstation setup while making the system safer overall. I see no downside to making that change.
josh
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, May 13, 2015 11:24:14 AM Subject: Re: Fedora 22 update security
On Wed, May 13, 2015 at 11:14 AM, Christian Schaller cschalle@redhat.com wrote:
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, May 13, 2015 10:27:23 AM Subject: Re: Fedora 22 update security
On Wed, May 13, 2015 at 10:00 AM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
And only admin users can reboot the machine while other users are using it...
Even in that scenario I'm don't believe allowing non-admin users to apply updates is the correct thing to do. I mean, your friend is over and turns on your laptop and logs into the non-admin account he created. He sees updates and says to apply them (via offline updates or not). He reboots the machine since he's the only logged in user. Now you have a bunch of updates applied that you didn't know about the next time you log in.
This really seems like a bad idea to me.
Well I guess it comes down to who we design the default install experience towards. My take is that our primary target is people on single user system with the idea being that people in more complex setups would be installing using kickstarts and similar and thus be able to tweak the configuration of such systems to suit their requirements (what tooling we offer or lack of such for helping with such tweaking is another debate).
So even in the single user scenario I can see that examples as the one you mentioned can happen, but I can't help but feel that the problem here is with your friend and not the system for assuming he should feel free to update your machine without asking you.
We're going to have to disagree then. The problem isn't with a friend. If the system allows a user with 0 privileges on the system to potentially majorly change the system, it's a problem with the system. I could come up with other scenarios involving kids using a shared family laptop and terrible analogies about loaded guns with no safety, but I'm trying to avoid hyperbole.
That said this is not a major issue to me as the default behaviour should be here that the first user created on a system should be in the wheel group (which we need to fix as this does not happen if you set up your user using Anaconda, but it is the case if you set up your user using the GNOME initial install wizard.)
Sure, the default cases are all covered and mostly unimpacted because the first user should be an admin. I agree. What I disagree with is saying that is good enough and leaving the non-admin user hole around. Put another way, changing the policy to prevent non-admin users from applying updates does not impact the default Workstation setup while making the system safer overall. I see no downside to making that change.
josh
Yeah, although if we are going to make that change I we should do the change in Anaconda at the same time, ensuring that the first user account is in the wheels group. Or alternative if its simpler, just disable the account creation in Anaconda.
Christian
On Wed, May 13, 2015 at 12:15:13PM -0400, Christian Schaller wrote:
Yeah, although if we are going to make that change I we should do the change in Anaconda at the same time, ensuring that the first user account is in the wheels group. Or alternative if its simpler, just disable the account creation in Anaconda.
I think we're probably past the time for that kind of change for F22, unless you can get the Anaconda and QA teams really excited about it. :)
----- Original Message -----
From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, May 13, 2015 12:18:59 PM Subject: Re: Fedora 22 update security
On Wed, May 13, 2015 at 12:15:13PM -0400, Christian Schaller wrote:
Yeah, although if we are going to make that change I we should do the change in Anaconda at the same time, ensuring that the first user account is in the wheels group. Or alternative if its simpler, just disable the account creation in Anaconda.
I think we're probably past the time for that kind of change for F22, unless you can get the Anaconda and QA teams really excited about it. :)
Yeah, no problem with that. This issue with who can do updates, while something we should fix, isn't release blocking IMHO.
Christian
On Wed, 2015-05-13 at 12:22 -0400, Christian Schaller wrote:
Yeah, no problem with that. This issue with who can do updates, while something we should fix, isn't release blocking IMHO.
This is at best a F23-timespan issue.
Although I'm not opposed to prohibiting unprivileged users from applying updates, we have a technical problem in polkit: we don't want to force admin users to enter a password to apply updates, but horrible workarounds (which we use in gnome-control-center and maybe now ABRT) are required to allow admins but not standard users to bypass authentication. Also, the polkit maintainer (Miloslav) doesn't want to change this: he likes password prompts to protect against the chance somebody gains physical access to your computer while you're logged in.
I think we need to fix polkit before we start adding more authentication prompts. We basically want a rule auth_if_nonadmin.
For details, see https://lists.fedorahosted.org/pipermail/crash -catcher/2015-April/005597.html
On Wed, May 13, 2015 at 01:14:03PM -0500, Michael Catanzaro wrote:
I think we need to fix polkit before we start adding more authentication prompts. We basically want a rule auth_if_nonadmin.
For details, see https://lists.fedorahosted.org/pipermail/crash -catcher/2015-April/005597.html
As a special-purpose single user environment Workstation can ship a Javascript snippet (matching the wheel group) without violating those rules from the polkit manual, right? ☺
Ship it as part of workstation customization?
On Thu, 2015-05-14 at 00:23 +0200, Lars Seipel wrote:
As a special-purpose single user environment Workstation can ship a Javascript snippet (matching the wheel group) without violating those rules from the polkit manual, right? ☺
I don't care about violating the rules from the manual, since the maintainer doesn't like the rules. But:
* Javascript is really unwieldy for this purpose, more a workaround than anything. * We want to upstream our changes, and shouldn't hardcode the admin group as wheel: that's not true on Debian or Ubuntu, for instance.
Michael
On Wed, May 13, 2015 at 05:35:47PM -0500, Michael Catanzaro wrote:
- Javascript is really unwieldy for this purpose, more a workaround
than anything.
Sure, but it's a three-line fix that could be made until a better mechanism exists.
- We want to upstream our changes, and shouldn't hardcode the admin
group as wheel: that's not true on Debian or Ubuntu, for instance.
What's to upstream here? It's an admin policy decision which, when the target audience is home users, might be set to something sensible by the distro. What does upstream have to do with it?
On Thu, 2015-05-14 at 01:27 +0200, Lars Seipel wrote:
What's to upstream here? It's an admin policy decision which, when the target audience is home users, might be set to something sensible by the distro. What does upstream have to do with it?
It never even occurred to me that we might make this change downstream, since we make changes upstream whenever we can. PackageKit is maintained by a Fedora developer (Richard Hughes) so it's natural that the default settings are what Fedora wants them to be.
On 14 May 2015 at 01:57, Michael Catanzaro mcatanzaro@gnome.org wrote:
It never even occurred to me that we might make this change downstream, since we make changes upstream whenever we can. PackageKit is maintained by a Fedora developer (Richard Hughes) so it's natural that the default settings are what Fedora wants them to be.
I'm certainly hope I'm a friendly upstream, and it's true that I want to ship sane policy by default. It doesn't mean upstream *has* to bend and flex to every diktat from FESCo. If someone can explain to me in an upstream bug why changing the policy would be more secure for users then I'll happily change it for the next release. I'm not horribly keen on the "lock down by default" arguments, as PackageKit upstream is at targeting these users http://www.freedesktop.org/software/PackageKit/pk-profiles.html
Richard
I checked my sudoers file and the user's group. I am confident that the user is a standard user and not a sudoer or in the wheel group.
I have been following the discussions on this and would like to comment on a few
1. I prefer KDE over Gnome. So on Fedora 20 I used kdm using my kickstart.
2. I upgraded to Fedora 21 and to 22 using the fedup tool, which requires one to mention what product they want. So I mentioned the product 'workstation', which got installed and I got a whole new display, that I do not like. I revert to KDE Plasma workspace.
3. The most important thing about this discussion is whether allow non-admin users to do system update or not. I WOULD PREFER NON-ADMIN USERS NOT TO GET THESE RIGHTS.
The reason is that I have had a serious issue from kernel update 3.16 to 3.19. The way they mount the CIFS share, I am still not able to understand certain behaviour. This is definitely not acceptable in a multi-user environment where the clients use LDAP, CIFS or NIS or any such remote server for login or folder authentication.
A standard user performing the updates would violate these settings and the system would not perform as expected or at least set by the system administrator. This means there is more work for system administrator and if cannot find a fix, then have to wait for a fix in the next release or as the discussion goes, there might not be any fix at all.
I usually test the updates on a system and make sure that it does not affect any normal use. Then I update it for every user or every client machines.
I do not understand which system administrator did not want an authentication or confirmation before installing updates. This could be TRUE only when the system administrator is logged into the system in GUI mode or on a terminal using 'su' command.
All I request is to give an option at least during the install or in kickstart to add a line that will say whether all users can install the system updates (whether offline or live) or not. So, it is then the admin's responsibility to deal with it.
This should come during the installation setup, where the installation source, admin password and other details are setup.
Thanks Nethaji
On Thu, 2015-05-14 at 07:21 +0100, Richard Hughes wrote:
On 14 May 2015 at 01:57, Michael Catanzaro mcatanzaro@gnome.org wrote:
It never even occurred to me that we might make this change downstream, since we make changes upstream whenever we can. PackageKit is maintained by a Fedora developer (Richard Hughes) so it's natural that the default settings are what Fedora wants them to be.
I'm certainly hope I'm a friendly upstream, and it's true that I want to ship sane policy by default. It doesn't mean upstream *has* to bend and flex to every diktat from FESCo. If someone can explain to me in an upstream bug why changing the policy would be more secure for users then I'll happily change it for the next release. I'm not horribly keen on the "lock down by default" arguments, as PackageKit upstream is at targeting these users http://www.freedesktop.org/software/PackageKit/pk-profiles.html
Richard
On Thu, May 14, 2015 at 12:21 AM, Richard Hughes hughsient@gmail.com wrote:
On 14 May 2015 at 01:57, Michael Catanzaro mcatanzaro@gnome.org wrote:
It never even occurred to me that we might make this change downstream, since we make changes upstream whenever we can. PackageKit is maintained by a Fedora developer (Richard Hughes) so it's natural that the default settings are what Fedora wants them to be.
I'm certainly hope I'm a friendly upstream, and it's true that I want to ship sane policy by default. It doesn't mean upstream *has* to bend and flex to every diktat from FESCo. If someone can explain to me in an upstream bug why changing the policy would be more secure for users then I'll happily change it for the next release. I'm not horribly keen on the "lock down by default" arguments, as PackageKit upstream is at targeting these users http://www.freedesktop.org/software/PackageKit/pk-profiles.html
Suzan should be a standard user, not admin, her brother is admin and does OS updates, she shouldn't be able to initiate them. She can install apps from approved sources and update them.
Brevan is admin of his own computer and can do whatever he wants.
Graham should not be using Fedora. But if he is, he's a standard user. He can install software from approved sources, and those applications can be updated. OS updates are off limits, his son will have to do that for him.
And I'm saying this as an OS X user, with parents with OS X systems. They can install app store and signed applications. I *think* they can do drag and drop application installs for their user only, I haven't tested that in a while. But they definitely can't do system updates. I do that. And OS X system updates are 1-2 orders magnitude more stable and sane than Windows updates, in my estimation. There is absolutely zero possibility I'd subject Suzan, Graham, or my parents to automatic OS updates, be it Windows, OS X or Fedora.
Hello Michael,
The fix you gave for the non-admin update the rule on May 13th (see below) does not work. After placing a file in the path /etc/polkit-1/rules.d/ and rebooting the system, standard user can still do the update. This included everything installed on the system. So a non-admin can modify the '/' folder when the updates are available.
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update") { return polkit.Result.AUTH_ADMIN; } });
Nethaji
________________________________________ From: desktop-bounces@lists.fedoraproject.org desktop-bounces@lists.fedoraproject.org on behalf of Chris Murphy lists@colorremedies.com Sent: 15 May 2015 03:39 To: Discussions about development for the Fedora desktop Subject: Re: Fedora 22 update security
On Thu, May 14, 2015 at 12:21 AM, Richard Hughes hughsient@gmail.com wrote:
On 14 May 2015 at 01:57, Michael Catanzaro mcatanzaro@gnome.org wrote:
It never even occurred to me that we might make this change downstream, since we make changes upstream whenever we can. PackageKit is maintained by a Fedora developer (Richard Hughes) so it's natural that the default settings are what Fedora wants them to be.
I'm certainly hope I'm a friendly upstream, and it's true that I want to ship sane policy by default. It doesn't mean upstream *has* to bend and flex to every diktat from FESCo. If someone can explain to me in an upstream bug why changing the policy would be more secure for users then I'll happily change it for the next release. I'm not horribly keen on the "lock down by default" arguments, as PackageKit upstream is at targeting these users http://www.freedesktop.org/software/PackageKit/pk-profiles.html
Suzan should be a standard user, not admin, her brother is admin and does OS updates, she shouldn't be able to initiate them. She can install apps from approved sources and update them.
Brevan is admin of his own computer and can do whatever he wants.
Graham should not be using Fedora. But if he is, he's a standard user. He can install software from approved sources, and those applications can be updated. OS updates are off limits, his son will have to do that for him.
And I'm saying this as an OS X user, with parents with OS X systems. They can install app store and signed applications. I *think* they can do drag and drop application installs for their user only, I haven't tested that in a while. But they definitely can't do system updates. I do that. And OS X system updates are 1-2 orders magnitude more stable and sane than Windows updates, in my estimation. There is absolutely zero possibility I'd subject Suzan, Graham, or my parents to automatic OS updates, be it Windows, OS X or Fedora.
-- Chris Murphy -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Fri, 2015-05-15 at 18:23 +0000, Thiyagarajan, Nethaji wrote:
Hello Michael,
The fix you gave for the non-admin update the rule on May 13th (see below) does not work. After placing a file in the path /etc/polkit -1/rules.d/ and rebooting the system, standard user can still do the update. This included everything installed on the system. So a non -admin can modify the '/' folder when the updates are available.
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update") { return polkit.Result.AUTH_ADMIN; } });
Nethaji
Hi Nethaji,
I tested this today with pkcon and it worked for me. The unprivileged user is able to list updates, but as soon as he attempts to apply the updates an authentication prompt appears. I'm not sure why it didn't work for you. I named my file 60-updates.rules; perhaps if the file is sorted too low it won't work?
I will make one amendment: we should prohibit offline updates as well:
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update" || action.id == "org.freedesktop.packagekit.trigger-offline -update") { return polkit.Result.AUTH_ADMIN; } });
Michael
Hi Michael,
Apologies.
The rule file I named as 51-autoupdate.rules. I realized that the comment line should not be #, which I had in my previous file. I had put who sent the rules in the file as a comment.
I have now changed the comment line and updated with the new rule you sent.
Many Thanks Nethaji ________________________________________ From: desktop-bounces@lists.fedoraproject.org desktop-bounces@lists.fedoraproject.org on behalf of Michael Catanzaro mcatanzaro@gnome.org Sent: 15 May 2015 22:46 To: Discussions about development for the Fedora desktop Subject: Re: Fedora 22 update security
On Fri, 2015-05-15 at 18:23 +0000, Thiyagarajan, Nethaji wrote:
Hello Michael,
The fix you gave for the non-admin update the rule on May 13th (see below) does not work. After placing a file in the path /etc/polkit -1/rules.d/ and rebooting the system, standard user can still do the update. This included everything installed on the system. So a non -admin can modify the '/' folder when the updates are available.
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update") { return polkit.Result.AUTH_ADMIN; } });
Nethaji
Hi Nethaji,
I tested this today with pkcon and it worked for me. The unprivileged user is able to list updates, but as soon as he attempts to apply the updates an authentication prompt appears. I'm not sure why it didn't work for you. I named my file 60-updates.rules; perhaps if the file is sorted too low it won't work?
I will make one amendment: we should prohibit offline updates as well:
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update" || action.id == "org.freedesktop.packagekit.trigger-offline -update") { return polkit.Result.AUTH_ADMIN; } });
Michael
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Hi Michael,
I will update this thread when the new update becomes available Thanks Nethaji ________________________________________ From: desktop-bounces@lists.fedoraproject.org desktop-bounces@lists.fedoraproject.org on behalf of Thiyagarajan, Nethaji n.thiyagarajan@ucl.ac.uk Sent: 16 May 2015 08:25 To: Discussions about development for the Fedora desktop Subject: Re: Fedora 22 update security
Hi Michael,
Apologies.
The rule file I named as 51-autoupdate.rules. I realized that the comment line should not be #, which I had in my previous file. I had put who sent the rules in the file as a comment.
I have now changed the comment line and updated with the new rule you sent.
Many Thanks Nethaji ________________________________________ From: desktop-bounces@lists.fedoraproject.org desktop-bounces@lists.fedoraproject.org on behalf of Michael Catanzaro mcatanzaro@gnome.org Sent: 15 May 2015 22:46 To: Discussions about development for the Fedora desktop Subject: Re: Fedora 22 update security
On Fri, 2015-05-15 at 18:23 +0000, Thiyagarajan, Nethaji wrote:
Hello Michael,
The fix you gave for the non-admin update the rule on May 13th (see below) does not work. After placing a file in the path /etc/polkit -1/rules.d/ and rebooting the system, standard user can still do the update. This included everything installed on the system. So a non -admin can modify the '/' folder when the updates are available.
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update") { return polkit.Result.AUTH_ADMIN; } });
Nethaji
Hi Nethaji,
I tested this today with pkcon and it worked for me. The unprivileged user is able to list updates, but as soon as he attempts to apply the updates an authentication prompt appears. I'm not sure why it didn't work for you. I named my file 60-updates.rules; perhaps if the file is sorted too low it won't work?
I will make one amendment: we should prohibit offline updates as well:
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update" || action.id == "org.freedesktop.packagekit.trigger-offline -update") { return polkit.Result.AUTH_ADMIN; } });
Michael
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Hi Michael,
Sorry the rule did not work for me. I have three rules files in /etc/polkit-1/rules.d folder. They are 49-polkit-pkla-compat.rules 50-default.rules 60-updates.rules
The file 60-update.rules contains the rule you have sent.
I am attaching a snapshot of the terminal in which I have run pkcon update and it did not ask me for any authorization.
The kernel version is 4.0.3-300.fc22.i686+PAE.
This kernel was updated from 4.0.2 as a standard user.
Thanks Nethaji
________________________________________ From: desktop-bounces@lists.fedoraproject.org desktop-bounces@lists.fedoraproject.org on behalf of Thiyagarajan, Nethaji n.thiyagarajan@ucl.ac.uk Sent: 16 May 2015 09:02 To: Discussions about development for the Fedora desktop Subject: Re: Fedora 22 update security
Hi Michael,
I will update this thread when the new update becomes available Thanks Nethaji ________________________________________ From: desktop-bounces@lists.fedoraproject.org desktop-bounces@lists.fedoraproject.org on behalf of Thiyagarajan, Nethaji n.thiyagarajan@ucl.ac.uk Sent: 16 May 2015 08:25 To: Discussions about development for the Fedora desktop Subject: Re: Fedora 22 update security
Hi Michael,
Apologies.
The rule file I named as 51-autoupdate.rules. I realized that the comment line should not be #, which I had in my previous file. I had put who sent the rules in the file as a comment.
I have now changed the comment line and updated with the new rule you sent.
Many Thanks Nethaji ________________________________________ From: desktop-bounces@lists.fedoraproject.org desktop-bounces@lists.fedoraproject.org on behalf of Michael Catanzaro mcatanzaro@gnome.org Sent: 15 May 2015 22:46 To: Discussions about development for the Fedora desktop Subject: Re: Fedora 22 update security
On Fri, 2015-05-15 at 18:23 +0000, Thiyagarajan, Nethaji wrote:
Hello Michael,
The fix you gave for the non-admin update the rule on May 13th (see below) does not work. After placing a file in the path /etc/polkit -1/rules.d/ and rebooting the system, standard user can still do the update. This included everything installed on the system. So a non -admin can modify the '/' folder when the updates are available.
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update") { return polkit.Result.AUTH_ADMIN; } });
Nethaji
Hi Nethaji,
I tested this today with pkcon and it worked for me. The unprivileged user is able to list updates, but as soon as he attempts to apply the updates an authentication prompt appears. I'm not sure why it didn't work for you. I named my file 60-updates.rules; perhaps if the file is sorted too low it won't work?
I will make one amendment: we should prohibit offline updates as well:
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.system-update" || action.id == "org.freedesktop.packagekit.trigger-offline -update") { return polkit.Result.AUTH_ADMIN; } });
Michael
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Hello,
2015-05-16 23:15 GMT+03:00 Thiyagarajan, Nethaji n.thiyagarajan@ucl.ac.uk:
Hi Michael,
Sorry the rule did not work for me. I have three rules files in /etc/polkit-1/rules.d folder. They are 49-polkit-pkla-compat.rules 50-default.rules 60-updates.rules
The file 60-update.rules contains the rule you have sent.
I guess you might need to name the file so that it is applied before the default rules. Try e.g. 30-updates.rules.
Hi Joonas,
I still can't stop the standard user from using the pkcon or the gui to stop the updates installation.
I tried to remove the packagekit, but the unexpected happened, that it also removed the plasma-desktop package. I could not see my desktop again after logging in.
I had to reinstall plasma-desktop, which also installed PackageKit-qt5 and all of its components.
Nothing changed.
Anyway, thanks for your suggestion.
Hope it will get fixed in the stable release of F22.
Nethaji
On Sat, 2015-05-16 at 23:23 +0300, Joonas Sarajärvi wrote:
Hello,
2015-05-16 23:15 GMT+03:00 Thiyagarajan, Nethaji n.thiyagarajan@ucl.ac.uk:
Hi Michael,
Sorry the rule did not work for me. I have three rules files in /etc/polkit-1/rules.d folder. They are 49-polkit-pkla-compat.rules 50-default.rules 60-updates.rules
The file 60-update.rules contains the rule you have sent.
I guess you might need to name the file so that it is applied before the default rules. Try e.g. 30-updates.rules.
Josh Boyer píše v St 13. 05. 2015 v 10:27 -0400:
On Wed, May 13, 2015 at 10:00 AM, Bastien Nocera <bnocera@redhat.com
wrote:
----- Original Message -----
Actually that should not an issue since we only do offline updates, so there is no chance of one user updating software while another is using it.
And only admin users can reboot the machine while other users are using it...
Even in that scenario I'm don't believe allowing non-admin users to apply updates is the correct thing to do. I mean, your friend is over and turns on your laptop and logs into the non-admin account he created. He sees updates and says to apply them (via offline updates or not). He reboots the machine since he's the only logged in user. Now you have a bunch of updates applied that you didn't know about the next time you log in.
This really seems like a bad idea to me.
I don't like this behavior either. My mom uses Fedora, but I don't let her perform updates herself because our updates are not bullet-proof and I don't want her to end up with a broken system. I always do it myself and check if everything works afterwards when I visit her.
On one hand, we don't have any GUI for upgrades arguing that we don't have a reliable mechanism for it to expose upgrades to users, and on the other hand we allow anyone to perform updates who are also not 100% reliable.
I can imagine that sysadmins of classroom deployments may be unpleasantly surprised by this as well. They are supposed to look at updates settings more in detail, but I don't think one expects that the system behave this way by default.
Jiri
Is it alright for any normal user to update the kernel. In my experience I have seen quite a lot of difference between kernel versions. When a standard user updates already installed signed by Fedora software, it could lead to some issues which system admin might not be able to fix. For example, the downgrade option is available for one version below the currently installed version. This is not recursive, I mean, I cannot go from version 3 to version 1. I will be stuck with version 2. As a system admin it is not ideal in a real world.
Differences between kernels and even versions of software, I have seen and experiencing issues.
This is evolution email client, which I am currently editing to report to the forum.
The other key thing is the update of the NVIDIA graphics driver. I still have not managed to install NVIDIA graphics driver on my Fedora 22 even with the latest kernel.
Nethaji
On Wed, 2015-05-13 at 09:47 -0400, Christian Schaller wrote:
So I checked with Richard Hughes and the way the rules currently works is that there is a difference between install and update. If you want to install a new piece of software you need to be part of the wheel group, but any user can update already installed software as long as it is signed Fedora software. (Well technically they are not even doing that since updates are done offline these days).
Christian
----- Original Message -----
From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, May 13, 2015 9:07:28 AM Subject: Re: Fedora 22 update security
On Wed, May 13, 2015 at 07:49:34AM -0500, Michael Catanzaro wrote:
Actually, sorry, Matthew and I were wrong. We do allow unprivileged users to run software updates (provided all of the updates are cryptographically signed by Fedora). You can configure this behavior manually by creating a file in /etc/polkit-1/rules.d with the following contents (untested, should work):
Huh. Last time this came up in FESCo, I thought the decision was to keep the policy as it had been (passwordless updates for admin users only).
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
desktop@lists.fedoraproject.org
-
Bastien Nocera -
Chris Murphy -
Christian Schaller -
Jiri Eischmann -
Joonas Sarajärvi -
Josh Boyer -
Lars Seipel -
Mathieu Bridon -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Naheem Zaffar -
Nethaji -
Richard Hughes -
Thiyagarajan, Nethaji