So I figured that I'd write about the whole current "non-root users can install stuff" fiasco. Here's my take on it, drawing heavily from my $DAYJOB experience of being a sysadmin of many systems.
First, in order for this to work, as I understand it (I don't have a convenient F12 machine at the moment), you have to be sitting at the console of the machine. As much as I despise Microsoft, they wrote a great paper some time ago, the 10 Immutable Laws of Security. And it's one of these laws that I'll refer to here (and it's sort of obvious):
If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
Think about that for a minute - once someone has physical access to your machine, game over. This is true no matter if you're running Windows, Linux, z/OS, whatever. For a typical Fedora workstation, all that someone with physical access needs to do is intercept the grub prompt, boot into single user and not be prompted for a password to do so, and proceed to wreak whatever havoc he sees fit on your system.
When analyzed from this perspective, allowing a locally authenticated user to installed signed content from a signed repository isn't all that bad. Furthermore, when you look at Fedora's target audience, I don't see servers or large deployments anywhere in there. That obviously doesn't preclude people from using it in this way, but it's more fit to be a single-user desktop, where the user and administrator are the same person, and that user is physically situated at the console of that machine.
Note that the preceding paragraph is not intended to say that Fedora shouldn't be run on servers or that it has no place there, nor that we shouldn't cater to the needs of that user type. However, when considering the default settings, we should probably go with ones that are conducive to the use case of a single user desktop. If you wish to use Fedora in other ways, that's why we have spins, which can defaults of their own (which for a server spin, would likely not include PackageKit, include more sane (to that use case) PolicyKit defaults, etc.
Also, if you're using Fedora in some sort of large enterprise deployment where centralized control over what gets installed on the end-nodes is desirable, then you should be deploying custom policy in order to restrict this and likely many other aspects of the default desktop configuration (enforcing screen locking, strong passwords, account lockout, and any number of other things).
I did, however, like the idea that was floated on fedora-devel-list about having multiple policies for varying levels of control over the system.
I will concede that this should have been documented better, but with the threads o' doom on this topic, I do believe that there's plenty of documentation and awareness by this point :)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=286bd8ba-5d5b-4267-acdd-21012946322f)
First, in order for this to work, as I understand it (I don't have a convenient F12 machine at the moment), you have to be sitting at the console of the machine. As much as I despise Microsoft, they wrote a great paper some time ago, the 10 Immutable Laws of Security. And it's one of these laws that I'll refer to here (and it's sort of obvious):
If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
Think about that for a minute - once someone has physical access to your machine, game over. This is true no matter if you're running Windows, Linux, z/OS, whatever. For a typical Fedora workstation, all that someone with physical access needs to do is intercept the grub prompt, boot into single user and not be prompted for a password to do so, and proceed to wreak whatever havoc he sees fit on your system.
When analyzed from this perspective, allowing a locally authenticated user to installed signed content from a signed repository isn't all that bad. Furthermore, when you look at Fedora's target audience, I don't see servers or large deployments anywhere in there. That obviously doesn't preclude people from using it in this way, but it's more fit to be a single-user desktop, where the user and administrator are the same person, and that user is physically situated at the console of that machine.
Note that the preceding paragraph is not intended to say that Fedora shouldn't be run on servers or that it has no place there, nor that we shouldn't cater to the needs of that user type. However, when considering the default settings, we should probably go with ones that are conducive to the use case of a single user desktop. If you wish to use Fedora in other ways, that's why we have spins, which can defaults of their own (which for a server spin, would likely not include PackageKit, include more sane (to that use case) PolicyKit defaults, etc.
Also, if you're using Fedora in some sort of large enterprise deployment where centralized control over what gets installed on the end-nodes is desirable, then you should be deploying custom policy in order to restrict this and likely many other aspects of the default desktop configuration (enforcing screen locking, strong passwords, account lockout, and any number of other things).
I did, however, like the idea that was floated on fedora-devel-list about having multiple policies for varying levels of control over the system.
I will concede that this should have been documented better, but with the threads o' doom on this topic, I do believe that there's plenty of documentation and awareness by this point :)
When speaking of grub, please don't forget to mention that a bootloader password can be configured during install in anaconda. I do this on all my machines, even at home where nobody but me has physical access. So IMO single user mode is different and this argument doesn't hold up.
Indeed it could be, but that's not the default case.
"First, in order for this to work, as I understand it (I don't have a convenient F12 machine at the moment), you have to be sitting at the console of the machine."
Well. Not really. See comments on the bug, most usefully this one:
https://bugzilla.redhat.com/show_bug.cgi?id=534047#c179
it's quite trivial for anyone who has managed to compromise a system to the point of executing arbitrary code _remotely_ as a given user to fool PolicyKit into thinking he's sitting at a local console. So before it gets reverted (which it would be valuable to note is going to happen: everyone talking about this issue should be aware of https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html ), this change essentially makes it easier to parlay any remote code execution vulnerability into a root vulnerability. (Note that there are rather a few other circumstances where this is possible both in F12 and previous releases, but making it easier is never a good idea).