Re: PackageKit policy: background and plans
On Mon, 2009-11-23 at 19:01 -0500, Gregory Maxwell wrote: On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating jkeat...@j2solutions.net wrote: This is precisely the dialog that has been removed from F12 and is not planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. If I understand you correctly you are saying that even if this weakness were addressed (e.g. through whatever means make fast user switching secure) that the feature would not be re-introduced. Am I misunderstanding? If I am not misunderstand, can you point me to the real reason that this feature was removed? Your understanding is not correct. The 'feature that was removed' is retention of authorizations (for more than a very short period). PolicyKit 0.x had keep_always policies, which asked a user to authenticate for an operation just once and then kept that authorization indefinitely. These are what were removed in PolicyKit 1.x, leaving only the keep policies, which retain authorization for just a few minutes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. If done well this should even allow things like the webadmin role being allowed to update/install apache related packages. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tue, 24 Nov 2009, James Antill wrote: On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. If done well this should even allow things like the webadmin role being allowed to update/install apache related packages. See, this is the problem, with all the exceptions you'd need to codify it would make much more sense to document how to set them up and make it relatively easy to do so that the local admin can do so. Think of it like documentation for sudo but with docs that don't make everyone cry. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tuesday, 24 November 2009 at 16:24, James Antill wrote: On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. I can imagine an additional drop-down list of user roles on the user account creation screen in firstboot GUI. What you described above would be a home user. However, parents may not want to let their kids install all the games they can from Fedora software collection, so we'd also need some tool to manage allowed root-level actions associated with these roles. Looks like a kind of enhanced sudo to me. ;) Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tue, 2009-11-24 at 10:27 -0500, Seth Vidal wrote: On Tue, 24 Nov 2009, James Antill wrote: On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. If done well this should even allow things like the webadmin role being allowed to update/install apache related packages. See, this is the problem, with all the exceptions you'd need to codify it would make much more sense to document how to set them up and make it relatively easy to do so that the local admin can do so. Think of it like documentation for sudo but with docs that don't make everyone cry. Oh, I agree 100%. My bad for not explaining what I meant. I'm not saying the GUI pkg installer should come with the above as defaults, just that it should work towards being able to easily provide the above functionality. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/23/2009 07:01 PM, Gregory Maxwell wrote: On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating jkeat...@j2solutions.net wrote: This is precisely the dialog that has been removed from F12 and is not planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. That reason isn't /quite/ right. One big problem is that if you train a user to input the root password over and over, what he learns is to type the root password into a dialog box. The result is that when some non-privileged application asks for the root password so it can do bad things with it later, the user will type in the root password, and voila, a local attack against a user is now a root exploit. The way around this is role-based privileges, which is what polkit is implementing - it means that for some actions, the user is automatically authorized by being assigned a role (for some actions, that is by being a member of the desktop_admin_r group). For some actions, the user may need to prove that he's who he says by entering /his/ password, but not the root password. The user does not thus get trained to enter the root password into dialog boxes. The important part here is that there's granularity on the actions - it's not assume root access, it's assume access to start $task that performs $action, so a) if the fake dialog attack does occur, it's a password with limited abilities which gets betrayed, and b) the admin is not necessarily giving free reign to the user in the first place. The model here is actually pretty good. The policy was clearly not what it should have been, and documentation/communication of the various roles and the rollout plan could have been better. Though tbf, on the polkit side there's plenty of how this works documentation that is useful and thorough; the communication of the roles and associated policy itself, that is, how PackageKit is using polkit and what admins need to know to lock a machine down, is what I'm talking about. If I understand you correctly you are saying that even if this weakness were addressed (e.g. through whatever means make fast user switching secure) that the feature would not be re-introduced. Am I misunderstanding? I don't understand what it is you think fast user switching does. You're just logged on as a different user. It's just like being logged in with a different getty on tty2 than on tty1. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tue, 2009-11-24 at 14:22 -0500, Peter Jones wrote: On 11/23/2009 07:01 PM, Gregory Maxwell wrote: On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating jkeat...@j2solutions.net wrote: This is precisely the dialog that has been removed from F12 and is not planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. That reason isn't /quite/ right. One big problem is that if you train a user to input the root password over and over, what he learns is to type the root password into a dialog box. The result is that when some non-privileged application asks for the root password so it can do bad things with it later, the user will type in the root password, and voila, a local attack against a user is now a root exploit. Sure, that's _a_ problem ... assuming the user has been trained. But that's a _big_ assumption, esp. when we are only talking about installing _new_ packages (doesn't happen often, so the user isn't trained to accept it). But, of course, taking advantage of a user trained to input a password without thinking is not the only attack ... another area of attack would be when you have an assumed small privilege escalation, that has no authentication (hence this thread). The way around this is role-based privileges, which is what polkit is implementing In so far as role-based privileges is code for can be configured to N number of actual checks, including the auth_as_root check we are comparing it against. Then sure, it has to be at least as secure as auth_as_root because it can be auth_as_root¹. But suggesting that whatever polkit is configured to use is automatically better than auth_as_root is, at best, misleading. Personally I don't think _anyone_ knows how to make a usable and thus. in practice secure desktop. So some of the comments I've read saying basically We know X is insecure, so we are now using Y which is secure/better are not helping (in fact I'd suggest that this mindset is what lead to this problem initially). ¹ Noting that polkit force removed the remember auth option, for no particularly sane reason that I've seen ... so if that option turns out to be the best option, then role-based privileges has (at least currently) hurt security. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/24/2009 03:49 PM, James Antill wrote: On Tue, 2009-11-24 at 14:22 -0500, Peter Jones wrote: That reason isn't /quite/ right. One big problem is that if you train a user to input the root password over and over, what he learns is to type the root password into a dialog box. The result is that when some non-privileged application asks for the root password so it can do bad things with it later, the user will type in the root password, and voila, a local attack against a user is now a root exploit. Sure, that's _a_ problem ... That's what I said, yes. assuming the user has been trained. But that's a _big_ assumption, No, not that they /have been/ trained. That the policy in question has the ability to train many users. I think this is ,in fact, a very /small/ assumption. esp. when we are only talking about installing _new_ packages (doesn't happen often, so the user isn't trained to accept it). We were discussing the dialog box in general, and not necessarily only this specific use of it. But, of course, taking advantage of a user trained to input a password without thinking is not the only attack ... another area of attack would be when you have an assumed small privilege escalation, that has no authentication (hence this thread). Yes, but it's often helpful to talk about specific improvements that can be made, not merely all problems that may emerge on a system. Or, to put that a different way, your thesis in this statement is that everywhere there's privilege escalation without secondary authentication is a risk. While that's certainly not incorrect, I don't think there's really much utility in discussing potential attack vectors in /bin/ping in *this* thread. The way around this is role-based privileges, which is what polkit is implementing In so far as role-based privileges is code for can be configured to N number of actual checks, including the auth_as_root check we are comparing it against. Then sure, it has to be at least as secure as auth_as_root because it can be auth_as_root¹. It's a fair point that the policy as defined for the role still needs to be a good one, but I think some people on this thread are dwelling on the mistake that was made, while at the same time placing blame incorrectly on the mechanism. That doesn't help us. The mechanism does improve things if used well by application developers and admins. But suggesting that whatever polkit is configured to use is automatically better than auth_as_root is, at best, misleading. I wasn't meaning to suggest that the system as a whole is necessarily more secure if you use a mechanism which allows for policy and role based decision making. I am suggesting that it certainly appears to be a good method to make a system which allows for /less/ privilege escalation on the whole while at the same time making a system which is more usable where individual authorized users don't /need/ more privileges. That's improvement. For it to also be more secure, it's true that the policies that govern the mechanism also have to be crafted in such a way as to enforce security. But that's true with what we had before, too. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, 2009-11-23 at 18:32 -0500, Seth Vidal wrote:
On Mon, 23 Nov 2009, Colin Walters wrote:
On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote:
Possibly (it could simply be that an updated policy is weaker for some
reason) -- but it doesn't matter, there should be no way to change MAC
policy without MAC privilege.
It'd be nice here if we had the ability to only grant the ability to
install applications, not packages. We could possibly do this even
now inside PackageKit by always downloading the filelists data, and
looking for a .desktop file. It'd be even better if we could get at
the data inside the .desktop file, but that's not necessary for this.
That leaves aside the packagekit-command-not-found feature for unix
binaries, but that's more of a technical use case.
Or - you could more easily generate the 'which pkgs have .desktop files'
and propagate that into a package Provides.
since yum can install by provides - that takes care of that need.
example:
Provides: App('foo')
-sv
Would it be possible to do this similarly to Conary... only installing
the files (.so's and things in /etc and /usr/share/{icons,sounds,...}
etc) required by a given application (binary with .desktop file) ?
This would provide similar to package splitting, but because of version
control and something like google update, it can be effective to update
only those files and applications when its parts are updated upstream...
with something like presto only bringing in what changed, and something
like jigdo allowing you to download each file from a different mirror,
speeds can be quite quick and downloads quite small.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tue, 24 Nov 2009, Francis Earl wrote:
Would it be possible to do this similarly to Conary... only installing
the files (.so's and things in /etc and /usr/share/{icons,sounds,...}
etc) required by a given application (binary with .desktop file) ?
This would provide similar to package splitting, but because of version
control and something like google update, it can be effective to update
only those files and applications when its parts are updated upstream...
with something like presto only bringing in what changed, and something
like jigdo allowing you to download each file from a different mirror,
speeds can be quite quick and downloads quite small.
That would require massive changes to rpm.
it is not an undertaking that is likely to happen in my opinion.
-sv
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
Kevin Kofler kevin.kof...@chello.at writes: I never tick those boxes. I'd like to know how to get rid of them entirely. Upgrade to F12 (with the latest PackageKit update), there's no such checkbox in F12's PolicyKit. This is good. Also we should remember that user entering root password in user's session makes the user account practically equivalent to root (it can be seen as a protection against incidental damage, but not against a real attack). The only secure way has to use a fully trusted path from the person to the root process - e.g. logging as root (or root-equivalent) initially, with a physically secured console (some sysrq-k or ctrl-alt-del combo which cannot be remapped or blocked by non-root etc). E.g. using su or in most cases sudo etc. makes the non-root account equivalent to root. This can be, of course, deemed secure as long as we accept and understand this equivalency. -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
James Morris (jmor...@namei.org) said: MAC policy can be updated without administrative privilege, breaking our MAC model in a fundamental way. I'm fairly sure that's wrong as well. Installation of another policy does not override the current one. What about when the system is rebooted? One scenario here is where the admin has made local modifications, which are then discarded by an upgrade of the policy. It should not be possible. Your complaint appeared to be that someone could switch from targeted to minimal (or similar) by simply installing the other package. It *does not work that way*, and it never has. If you're saying that an upgrade to a later targeted policy might break the local customizations, doesn't that mean the targeted policy maintainer made a mistake? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, Nov 23, 2009 at 9:37 AM, Krzysztof Halasa k...@pm.waw.pl wrote: Kevin Kofler kevin.kof...@chello.at writes: I never tick those boxes. I'd like to know how to get rid of them entirely. Upgrade to F12 (with the latest PackageKit update), there's no such checkbox in F12's PolicyKit. This is good. Also we should remember that user entering root password in user's session makes the user account practically equivalent to root (it can be seen as a protection against incidental damage, but not against a real attack). The only secure way has to use a fully trusted path from the person to the root process - e.g. logging as root (or root-equivalent) initially, with a physically secured console (some sysrq-k or ctrl-alt-del combo which cannot be remapped or blocked by non-root etc). E.g. using su or in most cases sudo etc. makes the non-root account equivalent to root. This can be, of course, deemed secure as long as we accept and understand this equivalency. There are many kinds of security threat out there. For example, a few dishonest people within the fedora project could conspire to backdoor the heck out of Fedora with a reasonable chance of not getting caught. Does this fact mean that we should not bother with signing packages or other security measures? Likewise, someone could load up some kind of X sniffer that intercepts the root password when its typed in. Someone could also break into your house and take apart your computer. Yet in many environments these threats are insignificant compared to a co-worker or family member casually twiddling around with the machine. I haven't tried the the fast user switching in fedora... Hopefully it is using some kernel mode secure path to prevent users from stealing each others credentials, if it isn't then one should be established for it. Why not use the same facility to switch to a system administration desktop, locked down a bit by default (use SE linux to make various unsafe user tasks like firefox, open office, etc unable to run in this admin context) to discourage casual use. Surely this would be preferable to reducing the security against common casual threats. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/23/2009 01:24 PM, Gregory Maxwell wrote: I haven't tried the the fast user switching in fedora... Hopefully it is using some kernel mode secure path to prevent users from stealing each others credentials, if it isn't then one should be established for it. Why not use the same facility to switch to a system administration desktop, locked down a bit by default (use SE linux to make various unsafe user tasks like firefox, open office, etc unable to run in this admin context) to discourage casual use. Wait, you're arguing for this *instead* of finer-grained elevations of privilege governed by policy files which can be locally overridden safely? Surely this would be preferable to reducing the security against common casual threats. I think you've characterized things backwards here. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
Gregory Maxwell gmaxw...@gmail.com writes: There are many kinds of security threat out there. For example, a few dishonest people within the fedora project could conspire to backdoor the heck out of Fedora with a reasonable chance of not getting caught. Does this fact mean that we should not bother with signing packages or other security measures? I didn't suggest anything like that, did I? Surely this would be preferable to reducing the security against common casual threats. I'm not talking about reducing security. su, sudo are already suid root (on most systems at least, especially su). Yes, this is, or at least may be, a security risk. Admin entering root's password in insecure session to install software is another security risk. That obviously doesn't mean I want non-root users to install system software at will. I just say that when it comes to entering the root password (and/or installing system software), it should be done in a secure manner, preferably not from within user X session (unless the risk = the fact of user = root equivalency is explicitly and specifically understood and accepted). -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, 23 Nov 2009, Bill Nottingham wrote: One scenario here is where the admin has made local modifications, which are then discarded by an upgrade of the policy. It should not be possible. Your complaint appeared to be that someone could switch from targeted to minimal (or similar) by simply installing the other package. It *does not work that way*, and it never has. If you're saying that an upgrade to a later targeted policy might break the local customizations, doesn't that mean the targeted policy maintainer made a mistake? Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. - James -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. We could possibly do this even now inside PackageKit by always downloading the filelists data, and looking for a .desktop file. It'd be even better if we could get at the data inside the .desktop file, but that's not necessary for this. That leaves aside the packagekit-command-not-found feature for unix binaries, but that's more of a technical use case. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, Nov 23, 2009 at 2:13 PM, Peter Jones pjo...@redhat.com wrote: On 11/23/2009 01:24 PM, Gregory Maxwell wrote: I haven't tried the the fast user switching in fedora... Hopefully it is using some kernel mode secure path to prevent users from stealing each others credentials, if it isn't then one should be established for it. Why not use the same facility to switch to a system administration desktop, locked down a bit by default (use SE linux to make various unsafe user tasks like firefox, open office, etc unable to run in this admin context) to discourage casual use. Wait, you're arguing for this *instead* of finer-grained elevations of privilege governed by policy files which can be locally overridden safely? I'm arguing for a secure way for users to obtain authoization to perform administrative operations instead of elevating them by default, and expecting the computer operator to go and hunt down the moving target of security holes in every new version of Fedora. This isn't mutually exclusive with finer-grained elevations but would allow finer grained elevations to stay out of the default install: When additional privileged is needed, the system prompts you to authenticate via a secure prompt. At that point if you have the required credentials you could authorize the activity and, optionally, permit that account to perform the same operation in the future. Obviously this kind of one-off permission granting isn't reasonable in a large environment, but large environments are the place where customize the policy is a workable answer especially when the systems is secure by default and customization can be applied selectively at the greatest pain points. This is a point I think people miss when advancing the position that it's only to be less secure for convince sake as you can customize your way out of a security hole: Customization has a non-trivial cost. If it didn't we'd all run build our systems from scratch rather than using distributions. To customize you must learn, understand, and track changes from version to version. If you're only customizing to make your systems easier the customization trade-off is easy to balance: When something annoys you, you learn about and then customize only that. But when you need to customize to get the expected security behaviour you must carefully evaluate all the security properties because insecurity is largely invisible until its too late. Surely this would be preferable to reducing the security against common casual threats. I think you've characterized things backwards here. Perhaps. I know that in my environment someone running software on my account to sniff the credentials is less likely than someone sitting at my computer and twiddling knobs while I walk away (but not long enough to get away with rebooting the system). If they could sit at my account they could start up such a sniffer, but the sort of people who would screw with my systems probably wouldn't. On Mon, Nov 23, 2009 at 4:40 PM, Krzysztof Halasa k...@pm.waw.pl wrote: I'm not talking about reducing security. su, sudo are already suid root (on most systems at least, especially su). Yes, this is, or at least may be, a security risk. Admin entering root's password in insecure session to install software is another security risk. That obviously doesn't mean I want non-root users to install system software at will. Though this isn't necessary. A facility to obtain elevated authority could be provided which eliminates this risk. I just say that when it comes to entering the root password (and/or installing system software), it should be done in a secure manner, preferably not from within user X session (unless the risk = the fact of user = root equivalency is explicitly and specifically understood and accepted). Sorry— I thought you were taking the further position that because entering the password is also a risk, that it's okay to simply give subsets of privileged to users. You're correct. It's a risk which should and can be eliminated. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, 23 Nov 2009, Colin Walters wrote:
On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote:
Possibly (it could simply be that an updated policy is weaker for some
reason) -- but it doesn't matter, there should be no way to change MAC
policy without MAC privilege.
It'd be nice here if we had the ability to only grant the ability to
install applications, not packages. We could possibly do this even
now inside PackageKit by always downloading the filelists data, and
looking for a .desktop file. It'd be even better if we could get at
the data inside the .desktop file, but that's not necessary for this.
That leaves aside the packagekit-command-not-found feature for unix
binaries, but that's more of a technical use case.
Or - you could more easily generate the 'which pkgs have .desktop files'
and propagate that into a package Provides.
since yum can install by provides - that takes care of that need.
example:
Provides: App('foo')
-sv
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, 2009-11-23 at 18:06 -0500, Gregory Maxwell wrote: This isn't mutually exclusive with finer-grained elevations but would allow finer grained elevations to stay out of the default install: When additional privileged is needed, the system prompts you to authenticate via a secure prompt. At that point if you have the required credentials you could authorize the activity and, optionally, permit that account to perform the same operation in the future. This is precisely the dialog that has been removed from F12 and is not planned to be returned. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating jkeat...@j2solutions.net wrote: This is precisely the dialog that has been removed from F12 and is not planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. If I understand you correctly you are saying that even if this weakness were addressed (e.g. through whatever means make fast user switching secure) that the feature would not be re-introduced. Am I misunderstanding? If I am not misunderstand, can you point me to the real reason that this feature was removed? Thanks! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Sat, 21 Nov 2009, Matthew Garrett wrote: worked without a password or login or anything. For the envisioned 'desktop' model is there a reason to have multiple users for the default? Is there a reason to have anything but root? Yes. There's a range of acts that root is able to perform that even an admin user should not be able to perform without extra authentication. It's not even necessarily related to security - I don't want a bug in firefox resulting in it trying to write to /dev/sda rather than a file in my home directory, for instance. This needs to be enforced at the OS level, with an analyzable policy, so you can determine if this is possible or not. Install all signed packages from a Fedora repository may indeed include the ability to write to /dev/sda -- nobody really knows and you have no way to find out. Also, it should certainly be possible while the operation is running at full privilege. - James -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
James Morris wrote: On Fri, 20 Nov 2009, Matthew Garrett wrote: I don't think I'd agree with that. The common case for F10 and F11 will be for people to have installed a package once with the root password and then ticked the Remember authentication box. At that point, we have the same security exposure as we do with F12 (again, concentrating on the single-user machine case). I never tick those boxes. I'd like to know how to get rid of them entirely. Upgrade to F12 (with the latest PackageKit update), there's no such checkbox in F12's PolicyKit. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, 2009-11-20 at 21:28 -0500, Jeff Garzik wrote: On 11/20/2009 09:19 PM, James Morris wrote: Are we moving toward a model where the user and the administrator are no longer really separated? Things seem to be regressing according to whatever use-case some desktop developer thinks is important at the time. Agreed. Speaking even more generally, it seems we have abandoned the default to secure principle. just keep echoing back and forth like that and you'll be firmly convinced the world is ending tomorrow. the thesis seems quite comprehensively destroyed by, uh, the fact that we changed the policy. if no-one cared about the default to secure principle, why would we have changed anything? please don't extrapolate to absurdity, here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Thu, 19 Nov 2009, Conrad Meyer wrote: I think it's fair to say that having this happen as root would generally be worse than it happening as an unprivileged user. For the latter, the attacker would need to also then succeed with a local privilege escalation attack to the same effect. On the contrary. On the typical single user system, it's just as bad if an attacker can steal / delete / modify the user's files as it is if the attacker can modify / delete system files. Privilege escalation isn't needed to delete everything the single user cares about. Note that I said generally. In the specific case where the attacker only wants access to the user's files, can exploit an existing vulnerability to do so, and can also get the data back out without further privilege (if they want the data), then yes, it's game over at that point. There are many possible scenarios where an attacker would want more privileged access to the system, e.g. install rootkits/firmware kits, modify firewall settings, run network services, attack other systems, evade detection etc. IOW, the current landscape of windows malware, data-stealing worms, botnets and so on. Getting root access is much more valuable in the general case. There are also the separate issues, as I mentioned subsequently, of increasing the attack surface, breaking the MAC model, and executing at full system privilege (also, without further authorization). I think we're throwing away a lot of well-established security benefit in moving away from the simple model of using a root/wheel account (or sudo) for admin and a separate user account for everything else. - James -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, Nov 20, 2009 at 12:26 AM, Conrad Meyer ceme...@u.washington.edu wrote: On the contrary. On the typical single user system, it's just as bad if an attacker can steal / delete / modify the user's files as it is if the attacker can modify / delete system files. Privilege escalation isn't needed to delete everything the single user cares about. Not quite. For example, it's much easier to fix a system which has only had a user account compromised, since if you actually trust that its only the user account you can skip the full reinstall. This is also assuming a strictly single user system. With features like fast user switching it wouldn't be inadvisable or especially inconvenient to operate business and pleasure activities from separate accounts. I don't know anyone that does this today, but as it becomes easier to do so and if the systems don't continue to go down the route of giving the local accounts root access then it may be a practice which becomes common. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, Nov 20, 2009 at 04:09:15PM +1100, James Morris wrote: Many users limit their use of the root account to essential system maintenance, and run general purpose applications as a regular unprivileged user. I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. - The local session has a new means to execute in a high privilege context, i.e. that which is required to install the system itself. This is a problem alone -- everything which runs in this context is now a prime attack target. I don't think I'd agree with that. The common case for F10 and F11 will be for people to have installed a package once with the root password and then ticked the Remember authentication box. At that point, we have the same security exposure as we do with F12 (again, concentrating on the single-user machine case). I definitely agree that there's a whole range of cases where this isn't the behaviour you want. But for the vast majority of our users, I don't think there's a real security issue here. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, Nov 20, 2009 at 9:34 AM, Matthew Garrett m...@redhat.com wrote: On Fri, Nov 20, 2009 at 04:09:15PM +1100, James Morris wrote: Many users limit their use of the root account to essential system maintenance, and run general purpose applications as a regular unprivileged user. I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. I do! And I tell everyone else too, so they learn/understand the difference between 'god' and a 'mere mortal user' (ie. root and anyone else). If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. ... snip ... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, Nov 20, 2009 at 09:38:43AM -0500, Fulko Hew wrote: I do! And I tell everyone else too, so they learn/understand the difference between 'god' and a 'mere mortal user' (ie. root and anyone else). Actually, thinking about it, even this isn't sufficient. An attacker could change the ctrl+alt+F* bindings and use them to pop up a full-screen window that looks like the console. So you'd also need to set up securetty to ensure that root can only log in on real consoles. I really don't see this being a security issue in the common single-user case. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
James Morris (jmor...@namei.org) said: - The local session can now install any signed packages from the Fedora repos: - I think this includes old versions of packages (correct?) Incorrect. MAC policy can be updated without administrative privilege, breaking our MAC model in a fundamental way. I'm fairly sure that's wrong as well. Installation of another policy does not override the current one. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/20/2009 10:04 AM, Matthew Garrett wrote: I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. I do that on critical workstations because a long time ago an old (fixed) bug killed my X session when updating and messed my system, so I do not trust too much updating base X components using a GUI. on my personal systems, yes I use the GUI method - The local session has a new means to execute in a high privilege context, i.e. that which is required to install the system itself. This is a problem alone -- everything which runs in this context is now a prime attack target. I don't think I'd agree with that. The common case for F10 and F11 will be for people to have installed a package once with the root password and then ticked the Remember authentication box. At that point, we have the same security exposure as we do with F12 (again, concentrating on the single-user machine case). I definitely agree that there's a whole range of cases where this isn't the behaviour you want. But for the vast majority of our users, I don't think there's a real security issue here. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, 2009-11-20 at 11:50 -0430, Robert Marcano wrote: On 11/20/2009 10:04 AM, Matthew Garrett wrote: I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. I do that on critical workstations because a long time ago an old (fixed) bug killed my X session when updating and messed my system, so I do not trust too much updating base X components using a GUI. on my personal systems, yes I use the GUI method This actually is one of the big advantages of PackageKit - because the installation is being done by a daemon rather than a process running in your session, if the X session dies during package installation, you won't be left with a half-completed transaction. Though that only helps from the command line if you use gpk-install-package-name rather than yum. Probably not too many people do that :-) - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, 20 Nov 2009, Owen Taylor wrote: On Fri, 2009-11-20 at 11:50 -0430, Robert Marcano wrote: On 11/20/2009 10:04 AM, Matthew Garrett wrote: I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. I do that on critical workstations because a long time ago an old (fixed) bug killed my X session when updating and messed my system, so I do not trust too much updating base X components using a GUI. on my personal systems, yes I use the GUI method This actually is one of the big advantages of PackageKit - because the installation is being done by a daemon rather than a process running in your session, if the X session dies during package installation, you won't be left with a half-completed transaction. Though that only helps from the command line if you use gpk-install-package-name rather than yum. Probably not too many people do that :-) if you install from the command line using yum and you're worried about the install obliterating your X session I would recommend using screen. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, 20 Nov 2009, Frank Ch. Eigler wrote: otaylor wrote: This actually is one of the big advantages of PackageKit - because the installation is being done by a daemon rather than a process running in your session, if the X session dies during package installation, you won't be left with a half-completed transaction. To what extent are yum/rpm/packagekit transactions databasey enough so that they can actually be undone if the machine or process crashes midstream? not enough. We can sometimes recover - it really depends on where it died :( -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, 20 Nov 2009, Matthew Garrett wrote: I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. This is how I started doing things in 1993, although I changed to sudo a few years back. - The local session has a new means to execute in a high privilege context, i.e. that which is required to install the system itself. This is a problem alone -- everything which runs in this context is now a prime attack target. I don't think I'd agree with that. The common case for F10 and F11 will be for people to have installed a package once with the root password and then ticked the Remember authentication box. At that point, we have the same security exposure as we do with F12 (again, concentrating on the single-user machine case). I never tick those boxes. I'd like to know how to get rid of them entirely. I definitely agree that there's a whole range of cases where this isn't the behaviour you want. But for the vast majority of our users, I don't think there's a real security issue here. Are we moving toward a model where the user and the administrator are no longer really separated? Things seem to be regressing according to whatever use-case some desktop developer thinks is important at the time. - James -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, 20 Nov 2009, Bill Nottingham wrote: MAC policy can be updated without administrative privilege, breaking our MAC model in a fundamental way. I'm fairly sure that's wrong as well. Installation of another policy does not override the current one. What about when the system is rebooted? One scenario here is where the admin has made local modifications, which are then discarded by an upgrade of the policy. It should not be possible. -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
PackageKit policy: background and plans
I wanted to provide an update to the list on the current thinking about the PackageKit policy issue from the perspective of the people working on the core desktop packages and on the desktop user experience. There was informal meeting earlier today with Richard Hughes, and myself, and a couple of people who could provide help with big-picture Fedora issues like Bill Nottingham and Jesse Keating, to try and figure out if there were obvious steps to take in the short term. Obviously there are lots and lots of people who care deeply about this, and there are discussions that need to continue, but with the delay in getting packages built, tested, and pushed out, we thought there were advantages to jump-starting things. If there was something obvious, then it made sense for the package maintainer (Richard) to just do it. I'm writing this mail somewhat by default: the people who really matter are the maintainers of the relevant packages, but Richard has gone to bed, and David Zeuthen and Matthias Clasen are on vacation this week. I'll try to reflect what they would say; much of it is certainly my own personal take on things instead. - Owen Where the Fedora 12 policy came from In Fedora 9, 10, and 11, the first time a user tried to install a package from the Fedora repositories, they would be prompted for a root password, with a checkbox to remember that permission for the future. (Before Fedora 9, you had to enter the root password every time.) We weren't really fully happy with this; this was basically asking the user to construct their own security policy. And not only that, but do it dialog-by-dialog, permission-by-permission as they tried to set up their Fedora system and get on with their life. From a more general perspective, the end effect of putting up a lot of dialogs: +---+ | | | A complicated explanation | | | | Root password [ ] | | | |[ OK ] | +---+ is that you are training users to blindly enter the root password and hit OK, *not* something that enhances the overall security of the system. There is an obvious better way to do this, which is to figure out what the appropriate roles are for the system: adminstrative users, non-adminstrative users, etc., and let the person maintaining system decide who gets what role. So, David Zeuthen did a major redesign of PolicyKit to move it from the old remembered permissions policy, to a model where users could be assigned different roles. See: https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html For some more details about how it works. The idea was that the change in PolicyKit would be accompanied by a default set of roles, and a nice user interface for assigning users to roles. Unfortunately, with the constraints of time, it became clear that this all (and especially the GUI) wasn't going to be there for Fedora 12. So, PackageKit needed a fixed policy for all users. For each action (install signed packages, install unsigned packages, remove packages, etc.), it needed to allow, deny, or ask for the root password. Among the decisions Richard made was allowing all users to install signed packages from the Fedora repositories. This was clearly the right behavior for the common case of a single-user system, where the only user is also the administrator. And it seemed pretty safe: Fedora isn't supposed to have packages in it that are dangerous to install. (For example, by policy, all network services must be off by default and not enabled by simply installing a package.) The reaction (why that probably wasn't the best choice) === There's obviously been a lot of feedback on this list and in other forums about this approach. And a lot of good points have brought up. 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. The other thing that is clear from the discussion is that we didn't do nearly enough communication about the change. I think was partly because the changes *weren't* finished. A rewrite of PolicyKit wasn't a feature in itself; the feature would have been the accounts dialog, which we didn't do for Fedora 12. But clearly the changes we did do had some major impacts that needed to be advertised. And while there are great low-level docs with all the details about PolicyKit configuration (see polkit(8) for a starting point to the docs), we didn't have the simple instructions for changing basic system policy. Moving forward from here
Re: PackageKit policy: background and plans
On 11/19/2009 09:29 PM, Owen Taylor wrote: Executive summary = We'll make an update to the F12 PackageKit, so that the root password is required to install packages. Thank you for the followup and attack plan. I also look forward to a policy configuration tool in F13. gene/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Thu, 19 Nov 2009, Owen Taylor wrote: Among the decisions Richard made was allowing all users to install signed packages from the Fedora repositories. This was clearly the right behavior for the common case of a single-user system, where the only user is also the administrator. I don't think this is clearly the right behavior at all. Many users limit their use of the root account to essential system maintenance, and run general purpose applications as a regular unprivileged user. This greatly limits the attack surface, i.e. the number of different ways in which a system might be compromised. System tools are also often more carefully designed, less complex, better tested, and better reviewed. I would usually not, for example, run a web browser as root, because it exposes a fairly complicated application to the global network. A bug in the browser's HTML parser might allow a remote attacker to take control of my shell session with an appropriately crafted page. I think it's fair to say that having this happen as root would generally be worse than it happening as an unprivileged user. For the latter, the attacker would need to also then succeed with a local privilege escalation attack to the same effect. With the new behavior, the attack surface is increased in several ways: - The local session has a new means to execute in a high privilege context, i.e. that which is required to install the system itself. This is a problem alone -- everything which runs in this context is now a prime attack target. - The local session can now install any signed packages from the Fedora repos: - I think this includes old versions of packages (correct?) with known and undisclosed vulnerabilities (old packages are particularly problematic because they're unmaintained) - It certainly includes all previously uninstalled current packages - Packages are installed globally, so the attack surface extends to other users who may end up using them (like root, or httpd), and not just the local user at the time MAC policy can be updated without administrative privilege, breaking our MAC model in a fundamental way. There are also several DoS scenarios. And it seemed pretty safe: Fedora isn't supposed to have packages in it that are dangerous to install. Software always has bugs, and some of those bugs will inevitably be security-relevant. Ideally, no packages will be dangerous to install, but we know that some will be. It is best practice to only install the packages which need to be installed, for this reason. (For example, by policy, all network services must be off by default and not enabled by simply installing a package.) Good. Executive summary = We'll make an update to the F12 PackageKit, so that the root password is required to install packages. Also good :-) Thanks for getting this resolved so quickly. - James -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Thursday 19 November 2009 09:09:15 pm James Morris wrote: On Thu, 19 Nov 2009, Owen Taylor wrote: Among the decisions Richard made was allowing all users to install signed packages from the Fedora repositories. This was clearly the right behavior for the common case of a single-user system, where the only user is also the administrator. I don't think this is clearly the right behavior at all. ... I think it's fair to say that having this happen as root would generally be worse than it happening as an unprivileged user. For the latter, the attacker would need to also then succeed with a local privilege escalation attack to the same effect. On the contrary. On the typical single user system, it's just as bad if an attacker can steal / delete / modify the user's files as it is if the attacker can modify / delete system files. Privilege escalation isn't needed to delete everything the single user cares about. Regards, -- Conrad Meyer ceme...@u.washington.edu -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
Thank you greatly for the well worded and well thought out response/update on the situation. In a thread of what was essentially a flame war, it is nice to see something constructive and meaningful emerge from the ashes. -Adam (From Android - CM) On Nov 19, 2009 8:30 PM, Owen Taylor otay...@redhat.com wrote: I wanted to provide an update to the list on the current thinking about the PackageKit policy issue from the perspective of the people working on the core desktop packages and on the desktop user experience. There was informal meeting earlier today with Richard Hughes, and myself, and a couple of people who could provide help with big-picture Fedora issues like Bill Nottingham and Jesse Keating, to try and figure out if there were obvious steps to take in the short term. Obviously there are lots and lots of people who care deeply about this, and there are discussions that need to continue, but with the delay in getting packages built, tested, and pushed out, we thought there were advantages to jump-starting things. If there was something obvious, then it made sense for the package maintainer (Richard) to just do it. I'm writing this mail somewhat by default: the people who really matter are the maintainers of the relevant packages, but Richard has gone to bed, and David Zeuthen and Matthias Clasen are on vacation this week. I'll try to reflect what they would say; much of it is certainly my own personal take on things instead. - Owen Where the Fedora 12 policy came from In Fedora 9, 10, and 11, the first time a user tried to install a package from the Fedora repositories, they would be prompted for a root password, with a checkbox to remember that permission for the future. (Before Fedora 9, you had to enter the root password every time.) We weren't really fully happy with this; this was basically asking the user to construct their own security policy. And not only that, but do it dialog-by-dialog, permission-by-permission as they tried to set up their Fedora system and get on with their life. From a more general perspective, the end effect of putting up a lot of dialogs: +---+ | | | A complicated explanation | | | | Root password [ ] | | | |[ OK ] | +---+ is that you are training users to blindly enter the root password and hit OK, *not* something that enhances the overall security of the system. There is an obvious better way to do this, which is to figure out what the appropriate roles are for the system: adminstrative users, non-adminstrative users, etc., and let the person maintaining system decide who gets what role. So, David Zeuthen did a major redesign of PolicyKit to move it from the old remembered permissions policy, to a model where users could be assigned different roles. See: https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html For some more details about how it works. The idea was that the change in PolicyKit would be accompanied by a default set of roles, and a nice user interface for assigning users to roles. Unfortunately, with the constraints of time, it became clear that this all (and especially the GUI) wasn't going to be there for Fedora 12. So, PackageKit needed a fixed policy for all users. For each action (install signed packages, install unsigned packages, remove packages, etc.), it needed to allow, deny, or ask for the root password. Among the decisions Richard made was allowing all users to install signed packages from the Fedora repositories. This was clearly the right behavior for the common case of a single-user system, where the only user is also the administrator. And it seemed pretty safe: Fedora isn't supposed to have packages in it that are dangerous to install. (For example, by policy, all network services must be off by default and not enabled by simply installing a package.) The reaction (why that probably wasn't the best choice) === There's obviously been a lot of feedback on this list and in other forums about this approach. And a lot of good points have brought up. 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. The other thing that is clear from the discussion is that we didn't do nearly enough communication about the change. I think was partly because the changes *weren't* finished. A rewrite of PolicyKit wasn't a feature in itself; the feature would have been the accounts dialog, which we didn't do for Fedora 12. But clearly the
