Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
On 11/18/2009 10:38 PM, nodata wrote:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
The subject of the mail doesn't actually match the description in the bug report. Richard Hughes says:
"PackageKit allows you to install signed content from signed repositories without a password by default. It only asks you to authenticate if anything is unsigned or the signatures are wrong"
If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help.
Rahul
2009/11/18 Rahul Sundaram sundaram@fedoraproject.org:
If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help.
Well, the security is dependent on the strength of the repository/package signature verification scheme. I am not sure how that is done exactly. Perhaps someone could shed some light.
2009/11/18 Rahul Sundaram sundaram@fedoraproject.org:
On 11/18/2009 10:38 PM, nodata wrote:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
The subject of the mail doesn't actually match the description in the bug report. Richard Hughes says:
"PackageKit allows you to install signed content from signed repositories without a password by default. It only asks you to authenticate if anything is unsigned or the signatures are wrong"
If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help.
Well, it's all a bit inconsistent presently:
$ yum install maxima Loaded plugins: presto, refresh-packagekit You need to be root to perform this command. $ maxima Command not found. Install package 'maxima' to provide command 'maxima'? [N/y] * Installing packages.. * Getting information.. * Resolving dependencies.. The following packages have to be installed: sbcl-1.0.30-2.fc12.x86_64 Steel Bank Common Lisp wxBase-2.8.10-6.fc12.x86_64 Non-GUI support classes from the wxWidgets library wxGTK-2.8.10-6.fc12.x86_64 GTK2 port of the wxWidgets GUI library gnuplot-common-4.2.6-1.fc12.x86_64 common gnuplot parts cl-asdf-20071110-7.fc12.noarch Another System Definition Facility gnuplot-4.2.6-1.fc12.x86_64 A program for plotting mathematical expressions and data maxima-runtime-sbcl-5.19.2-1.fc12.x86_64 Maxima compiled with SBCL common-lisp-controller-6.15-8.fc12.noarch Common Lisp source and compiler manager Proceed with changes? [N/y] * Waiting for authentication.. * Running.. * Resolving dependencies.. * Downloading packages.. * Testing changes.. * Installing packages.. * Scanning applications.. [jgu@withnail ~]$ Command not found. Install package 'maxima' to provide command 'maxima'? [N/y] ^C
... and what's more it bails with "command not found" anyway.... which component isn't working here?
2009/11/18 Jonathan Underwood jonathan.underwood@gmail.com:
Well, it's all a bit inconsistent presently: $ yum install maxima Loaded plugins: presto, refresh-packagekit You need to be root to perform this command.
yum isn't PackageKit. Different tools, different feature-sets.
Richard.
Am 2009-11-18 18:14, schrieb Rahul Sundaram:
On 11/18/2009 10:38 PM, nodata wrote:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
The subject of the mail doesn't actually match the description in the bug report. Richard Hughes says:
"PackageKit allows you to install signed content from signed repositories without a password by default. It only asks you to authenticate if anything is unsigned or the signatures are wrong"
If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help.
Rahul
Thanks. I have changed the title to: "All users get to install software on a machine they do not have the root password to"
On 11/18/2009 11:19 PM, nodata wrote:
Thanks. I have changed the title to: "All users get to install software on a machine they do not have the root password to"
.. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail.
Rahul
Am 2009-11-18 18:48, schrieb Rahul Sundaram:
On 11/18/2009 11:19 PM, nodata wrote:
Thanks. I have changed the title to: "All users get to install software on a machine they do not have the root password to"
.. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail.
Rahul
Why is it a problem? For all of the reasons that it has never been a problem before. For the reason that the user is not the administrator or the box, for the reason that the user is the user for a reason, for the reason that by default Linux should act like Linux, for the reason that the default is bad, for the reason that this is undocumented, for the reason that it assumes automatic updates are enabled, for the reason that the user is not the one with knowledge of the box and what resources are available on it, for the reason that it may be against corporate policy, for the reason of change management...
On 11/18/2009 11:27 PM, nodata wrote:
Why is it a problem? For all of the reasons that it has never been a problem before. For the reason that the user is not the administrator or the box, for the reason that the user is the user for a reason, for the reason that by default Linux should act like Linux, for the reason that the default is bad,
All of these seems rather circular.
for the reason that this is undocumented,
I have asked for more documentation already which I consider a valid point.
for the
reason that it assumes automatic updates are enabled,
I am not sure why you say that? Automatic updates are not enabled by default.
for the reason
that the user is not the one with knowledge of the box and what resources are available on it, for the reason that it may be against corporate policy, for the reason of change management...
Should the defaults be targeted towards home users or corporate desktop considering the short lifecycle of Fedora and the target audience? I am not sure there are corporate deployments but wouldn't they be heavily customized their desktop deployments and kickstarting it anyway?
Rahul
On Wed, 2009-11-18 at 23:29 +0530, Rahul Sundaram wrote:
Should the defaults be targeted towards home users or corporate desktop considering the short lifecycle of Fedora and the target audience? I am not sure there are corporate deployments but wouldn't they be heavily customized their desktop deployments and kickstarting it anyway?
I am not a corporation yet *I* manage the machines I have at home, and if *I* give an account to my friend foo *I* don't want him to be able to install nothing without asking me first, not even by mistake.
For better of worse even desktop Linux is a multi-user system and this default is just crap and totally unnecessary given the previous version allowed you to allow a user forever explicitly and without hassles.
This way I have to *fsck* remember each time to change it, this is *wrong*, it doesn't respect the basic philosophy of least surprise.
I would almost consider it a security vulnerability and ask for a CVE to be issued.
Simo.
On Wed, Nov 18, 2009 at 10:36:20PM +0000, Tim Waugh wrote:
On Wed, 2009-11-18 at 13:22 -0500, Simo Sorce wrote:
I would almost consider it a security vulnerability and ask for a CVE to be issued.
It certainly seems like an easy path to a denial of service: just install everything and run the machine out of disk space.
org.freedesktop.packagekit.system-network-proxy-configure also seems scary to me.
Verily I say unto thee, that Rahul Sundaram spake thusly:
On 11/18/2009 11:27 PM, nodata wrote:
Why is it a problem? For all of the reasons that it has never been a problem before. For the reason that the user is not the administrator or the box, for the reason that the user is the user for a reason, for the reason that by default Linux should act like Linux, for the reason that the default is bad,
All of these seems rather circular.
I don't find "the user is not the administrator" a circular argument.
Perhaps the reason that his arguments seems circular, is that he's having difficulty with the concept of having to spell-out the fundamental axioms of computer security ... on a developers list.
Let's try an analogy, and just for maximal irritation let's make it a car analogy, which I know everyone loves:
You drive your 12 year old son to school every day. In this sense, he is a user of the car. You fill the tank at the same gas station every day.
Would you give the keys of your car to your 12 year old son, and ask him to drive to the gas station, simply because your son is an authorised "user" of your car, and because you trust the quality of the fuel from that gas station?
Users are not, and should never be, administrators.
The assumption that every Fedora user is also the administrator on a single-user system, is just that ... an assumption, and one which is statistically highly unlikely to be universally correct.
Should those administrators of multi-user systems be subjected to this sort of insecurity by default?
And frankly, even if it were the case that Fedora was being universally rejected for server operation, I find this new policy an affront to the basic principles of UNIX security. And if you need further clarification on that highly impassioned opinion, then let me explain (as if I should need to do so) why the principle "do not take the name of thy root in vein" has attained the status of aphorism: If there is no clear separation of privileged from unprivileged access on a computer system, then privileged access quickly becomes the norm (a la Microsoft Windows), and thus every bleary-eyed mistake becomes a potentially fatal issue for the entire system, every user on that system, and possibly even further afield (e.g. spam-bots).
One look at the current pitiful state of Windows security should be more than sufficient explanation for why this new policy is the mother of all bad ideas.
Should the defaults be targeted towards home users or corporate desktop considering the short lifecycle of Fedora and the target audience?
Since when did security become optional in Linux?
Isn't it supposed to be one of the biggest (if not the biggest) differentiator from Windows?
And are you suggesting that corporate users, or any others in a multi-user environment, are not supposed to use Fedora?
Are there, in fact, no Fedora users in such an environment? And if there are, doesn't Fedora have a social responsibility to ensure that environment is secure be default, or indeed that Fedora in /any/ environment is secure by default?
I am not sure there are corporate deployments but wouldn't they be heavily customized their desktop deployments and kickstarting it anyway?
Maybe some are.
Inevitably, some won't be.
Error: Too many assumptions. Stack overflow.
On 11/19/2009 12:29 PM, Keith G. Robertson-Turner wrote:
Verily I say unto thee, that Rahul Sundaram spake thusly:
On 11/19/2009 11:51 AM, Keith G. Robertson-Turner wrote:
Error: Too many assumptions. Stack overflow.
Yes, you are making too many assumptions
Where?
Just stop.
Rahul
On Wed, Nov 18, 2009 at 23:18:28 +0530, Rahul Sundaram sundaram@fedoraproject.org wrote:
On 11/18/2009 11:19 PM, nodata wrote:
Thanks. I have changed the title to: "All users get to install software on a machine they do not have the root password to"
.. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail.
Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems.
On 11/18/2009 11:44 PM, Bruno Wolff III wrote:
Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems.
This assumes the user is different from a admin, which is not true for a personal desktop. This revolves back to what the default target audience should be. PackageKit target audience is defined at
http://www.packagekit.org/pk-profiles.html
If it doesn't match what Fedora wants, then it should be tweaked but the larger question should be addressed first.
Rahul
On 11/18/2009 01:14 PM, Rahul Sundaram wrote:
On 11/18/2009 11:44 PM, Bruno Wolff III wrote:
Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems.
This assumes the user is different from a admin, which is not true for a personal desktop. This revolves back to what the default target audience should be. PackageKit target audience is defined at
http://www.packagekit.org/pk-profiles.html
If it doesn't match what Fedora wants, then it should be tweaked but the larger question should be addressed first.
Rahul
Security-relevant defaults aren't set for the common case. They're set for the tightest case. For the desktop user maybe this works fine. For the server user, we've killed our security guarantee completely. It doesn't matter if you can change it. If the system boots so much as once with the default setup it may /already be too late/. By the admin's first opportunity to change the settings the box could already be rooted.
--CJD
2009/11/18 Casey Dahlin cdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
Richard.
Am 2009-11-18 20:20, schrieb Richard Hughes:
2009/11/18 Casey Dahlincdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
2009/11/18 nodata lsof@nodata.co.uk:
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
Why would the additional package start extra services? I thought there were guidelines about that. Anyway, if the user has physical access to the machine, there are many quicker ways to root the box in question. (Like rebooting, and using grub to go to runlevel 1)
Richard.
On 11/18/2009 02:29 PM, Richard Hughes wrote:
2009/11/18 nodata lsof@nodata.co.uk:
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
Why would the additional package start extra services? I thought there were guidelines about that. Anyway, if the user has physical access to the machine, there are many quicker ways to root the box in question. (Like rebooting, and using grub to go to runlevel 1)
Richard.
What if they don't? The mechanisms by which we are detecting and proving physical access are easily circumvented. If the buffer overflow allows arbitrary code execution, you need only an "open(/dev/console, ...)" to fool a lot of these mechanisms. Just because a program is interactive on a console does not mean that that's the /only/ place its being controlled from.
--CJD
2009/11/18 nodata lsof@nodata.co.uk:
Am 2009-11-18 20:20, schrieb Richard Hughes:
2009/11/18 Casey Dahlincdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it.
Regards,
Am 2009-11-18 20:30, schrieb Konstantin Ryabitsev:
2009/11/18 nodatalsof@nodata.co.uk:
Am 2009-11-18 20:20, schrieb Richard Hughes:
2009/11/18 Casey Dahlincdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it.
If the servers are in locked racks and you require a reboot to get access to a grub prompt which is not password protected, then the outage would trip the monitoring system.
On Wed, 2009-11-18 at 20:34 +0100, nodata wrote:
If the servers are in locked racks and you require a reboot to get access to a grub prompt which is not password protected, then the outage would trip the monitoring system.
The server is in a locked rack, but the console access to the server isn't? How far down the strawman path are where?
Am 2009-11-18 20:50, schrieb Jesse Keating:
On Wed, 2009-11-18 at 20:34 +0100, nodata wrote:
If the servers are in locked racks and you require a reboot to get access to a grub prompt which is not password protected, then the outage would trip the monitoring system.
The server is in a locked rack, but the console access to the server isn't? How far down the strawman path are where?
huh? All servers are in locked racks, with a few KVM terminals.
On Wed, 2009-11-18 at 21:28 +0100, nodata wrote:
Am 2009-11-18 20:50, schrieb Jesse Keating:
On Wed, 2009-11-18 at 20:34 +0100, nodata wrote:
If the servers are in locked racks and you require a reboot to get access to a grub prompt which is not password protected, then the outage would trip the monitoring system.
The server is in a locked rack, but the console access to the server isn't? How far down the strawman path are where?
huh? All servers are in locked racks, with a few KVM terminals.
The places I've cared about security of the systems wouldn't allow anybody without a key to our rack to access the console. You'd have to unlock the rack in order to access the KVM or to plug anything into the machines.
2009/11/18 nodata lsof@nodata.co.uk:
Am 2009-11-18 20:20, schrieb Richard Hughes:
2009/11/18 Casey Dahlincdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it.
So here is what I've just gotten from talking to Ray Strode and reading docs.
if you want to disable this just run:
pklalockdown --lockdown org.freedesktop.packagekit.package-install
that will keep anyone from installing pkgs w/o authenticating as admin.
That's the short version.
the long version I'm working on writing up right now.
-sv
Am 2009-11-18 21:27, schrieb Seth Vidal:
2009/11/18 nodata lsof@nodata.co.uk:
Am 2009-11-18 20:20, schrieb Richard Hughes:
2009/11/18 Casey Dahlincdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it.
So here is what I've just gotten from talking to Ray Strode and reading docs.
if you want to disable this just run:
pklalockdown --lockdown org.freedesktop.packagekit.package-install
that will keep anyone from installing pkgs w/o authenticating as admin.
That's the short version.
the long version I'm working on writing up right now.
-sv
Thanks for this. Does this need to be run as root? :)
On Wed, 18 Nov 2009, nodata wrote:
Am 2009-11-18 21:27, schrieb Seth Vidal:
2009/11/18 nodata lsof@nodata.co.uk:
Am 2009-11-18 20:20, schrieb Richard Hughes:
2009/11/18 Casey Dahlincdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it.
So here is what I've just gotten from talking to Ray Strode and reading docs.
if you want to disable this just run:
pklalockdown --lockdown org.freedesktop.packagekit.package-install
that will keep anyone from installing pkgs w/o authenticating as admin.
That's the short version.
the long version I'm working on writing up right now.
-sv
Thanks for this. Does this need to be run as root? :)
yes :) -sv
On Wed, 18 Nov 2009, Seth Vidal wrote:
2009/11/18 nodata lsof@nodata.co.uk:
Am 2009-11-18 20:20, schrieb Richard Hughes:
2009/11/18 Casey Dahlincdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it.
So here is what I've just gotten from talking to Ray Strode and reading docs.
if you want to disable this just run:
pklalockdown --lockdown org.freedesktop.packagekit.package-install
that will keep anyone from installing pkgs w/o authenticating as admin.
That's the short version.
the long version I'm working on writing up right now.
longer version w/some more details:
http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-...
-sv
Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions.
Instead of shielding yourselves with silly arguments about the lack of lock-and-key on a desktop machine, ask yourself how many decades-old assumptions you are wiping in one fell swoop. It's no excuse to give viruses, pranksters and other vectors easy access to Fedora.
Even Microsoft Windows asks for elevated privileges for this sort of thing!
This is just shameful.
Jeff
Jeff Garzik (jgarzik@pobox.com) said:
Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions.
Out of the box, a desktop user has the ability to shut down the machine. This gives them the ability, out of the box, to: - DoS everyone on it - get a root shell -- install whatever they want -- put viruses on - hell, slap in a livecd or USB key and reinstall the box
It's a behavior change, for sure. For people who want to lock down their systems, it's a default they will need to be able to change, and they should have been able to discover it through the normal mechanisms for that. (i.e., the release notes.). It likely should have been discussed when it was introduced - it's obviously not something that's applicable to all usage cases for the OS.
But really, given that users out of the box can do *far far worse*, I'm not seeing the 'shameful', 'antithetical', OMG THE SKY IS FALLING AND YOU ALL SHOULD BE DRAWN AND QUARTERED sort of angst. Maybe people are tired of bagging tea and want new things to be outraged about.
Bill
On Wed, Nov 18, 2009 at 3:23 PM, Bill Nottingham notting@redhat.com wrote:
But really, given that users out of the box can do *far far worse*, I'm not seeing the 'shameful', 'antithetical', OMG THE SKY IS FALLING AND YOU ALL SHOULD BE DRAWN AND QUARTERED sort of angst. Maybe people are tired of bagging tea and want new things to be outraged about.
I know I'm tired of bagging tea. Luckily for me there's a new bubble tea shop in town with free wifi. I can enjoy bagless tea all day long and still get work done.
-jef"needs a bubble tea protest t-shirt"spaleta
On 11/18/2009 07:23 PM, Bill Nottingham wrote:
Jeff Garzik (jgarzik@pobox.com) said:
Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions.
Out of the box, a desktop user has the ability to shut down the machine. This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want -- put viruses on
- hell, slap in a livecd or USB key and reinstall the box
How is any of that justification for lowering the security bar to zero?
All of those you list are more technically complex than the current F12 behavior -- letting the kids or guests click a button.
IFF this feature was listed as a question in firstboot, and IFF this feature was explained in detail in release notes, then there would have been no problem at all...
You also omitted the case where admins of servers upgrade into a less secure policy. PackageKit presence does not imply desktop user.
Jeff
On 11/18/2009 07:34 PM, Jeff Garzik wrote:
On 11/18/2009 07:23 PM, Bill Nottingham wrote:
Jeff Garzik (jgarzik@pobox.com) said:
Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions.
Out of the box, a desktop user has the ability to shut down the machine. This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want -- put viruses on
- hell, slap in a livecd or USB key and reinstall the box
How is any of that justification for lowering the security bar to zero?
All of those you list are more technically complex than the current F12 behavior -- letting the kids or guests click a button.
And it ignores that remote exploits are now much easier, because remote non-root exploit + package install == remote root exploit.
Jeff
On Wed, Nov 18, 2009 at 7:36 PM, Jeff Garzik jgarzik@pobox.com wrote:
And it ignores that remote exploits are now much easier, because remote non-root exploit + package install == remote root exploit.
No, the uid needs to have logged in through a physical console.
On 11/18/2009 07:37 PM, Colin Walters wrote:
On Wed, Nov 18, 2009 at 7:36 PM, Jeff Garzikjgarzik@pobox.com wrote:
And it ignores that remote exploits are now much easier, because remote non-root exploit + package install == remote root exploit.
No, the uid needs to have logged in through a physical console.
See references in multiple mails to firefox, pidgin, and any number of other example applications run by a uid logged in through a physical console.
Web browsers -- especially with bin-only flash -- are the most likely vector for remote exploits these days. Far more so than any system daemon.
There are Real Good(tm) reasons why Firefox complains, if your Flash plug-in is out of date, even on Linux...
Jeff
On Wed, 18 Nov 2009, Jeff Garzik wrote:
On 11/18/2009 07:23 PM, Bill Nottingham wrote:
Jeff Garzik (jgarzik@pobox.com) said:
Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions.
Out of the box, a desktop user has the ability to shut down the machine. This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want -- put viruses on
- hell, slap in a livecd or USB key and reinstall the box
How is any of that justification for lowering the security bar to zero?
We haven't lowered the security bar to zero. We don't mount home dirs noexec by default[1] so on the security level we're only talking about security vulnerabilities to suid packages. All of which could be installed via a reboot and grub changes *and* would require a vulnerability in that package, something we're very quick to fix. Though keeping N and N-1 versions on the mirror is a security vulnerability as the old version could always be pulled in.
All of those you list are more technically complex than the current F12 behavior -- letting the kids or guests click a button.
It also lets them keep the system up to date, there's an argument to be made here that this aspect is more secure.
IFF this feature was listed as a question in firstboot, and IFF this feature was explained in detail in release notes, then there would have been no problem at all...
I tend to agree with this. I believe this is similar to how ubuntu does it with some sort of opt-in.
You also omitted the case where admins of servers upgrade into a less secure policy. PackageKit presence does not imply desktop user.
I think you'd find your arguments would be better received if you weren't so dramatic about it. Stick with the facts, be clear about what you're trying to accomplish (changing it back in F13? Changing it back in F12? Setting a policy so stuff like this doesn't happen again?)
-Mike
[1] Talking about something as simple as rpm2cpio here
On 11/18/2009 07:45 PM, Mike McGrath wrote:
Stick with the facts, be clear about what you're trying to accomplish (changing it back in F13? Changing it back in F12? Setting a policy so stuff like this doesn't happen again?)
1) We should recognize this new policy departs from decades of Unix and Linux sysadmin experience.
2) F12 policy should be reverted to F11, ASAP. Possibly with a CVE.
3) Due to #1, F13+ should not deviate from the decades-old default.
4) Release notes should explain new [and after step #2, optional] policy in detail, including how to turn it off again. Seth's laudable write-up efforts should not have been necessary -- that info should be prepared.
5) The people who want this new security policy should add an opt-in checkbox in Anaconda or firstboot.
Jeff
On Wed, 18 Nov 2009, Jeff Garzik wrote:
On 11/18/2009 07:45 PM, Mike McGrath wrote:
Stick with the facts, be clear about what you're trying to accomplish (changing it back in F13? Changing it back in F12? Setting a policy so stuff like this doesn't happen again?)
- We should recognize this new policy departs from decades of Unix and Linux
sysadmin experience.
F12 policy should be reverted to F11, ASAP. Possibly with a CVE.
Due to #1, F13+ should not deviate from the decades-old default.
Release notes should explain new [and after step #2, optional] policy in
detail, including how to turn it off again. Seth's laudable write-up efforts should not have been necessary -- that info should be prepared.
- The people who want this new security policy should add an opt-in checkbox
in Anaconda or firstboot.
Does anyone disagree with anything in 1-5? It all sounds reasonable to me?
-Mike
On 11/19/2009 07:50 AM, Mike McGrath wrote:
On Wed, 18 Nov 2009, Jeff Garzik wrote:
- We should recognize this new policy departs from decades of Unix and Linux
sysadmin experience.
F12 policy should be reverted to F11, ASAP. Possibly with a CVE.
Due to #1, F13+ should not deviate from the decades-old default.
Release notes should explain new [and after step #2, optional] policy in
detail, including how to turn it off again. Seth's laudable write-up efforts should not have been necessary -- that info should be prepared.
- The people who want this new security policy should add an opt-in checkbox
in Anaconda or firstboot.
Does anyone disagree with anything in 1-5? It all sounds reasonable to me?
Release notes are being updated as we speak. I think, the "role" of a system, be it a personal desktop, workstation, server or something else can change post-installation as well. I don't think a simple checkbox in Anaconda is going to be useful enough. We need a tool to switch policies easily so that we can tweak the policies across a wide range of tools with things like PolicyKit and each of these policies can be written with particular audiences in mind.
Rahul
On Thu, 2009-11-19 at 07:52 +0530, Rahul Sundaram wrote:
On 11/19/2009 07:50 AM, Mike McGrath wrote:
On Wed, 18 Nov 2009, Jeff Garzik wrote:
- We should recognize this new policy departs from decades of Unix and Linux
sysadmin experience.
F12 policy should be reverted to F11, ASAP. Possibly with a CVE.
Due to #1, F13+ should not deviate from the decades-old default.
Release notes should explain new [and after step #2, optional] policy in
detail, including how to turn it off again. Seth's laudable write-up efforts should not have been necessary -- that info should be prepared.
- The people who want this new security policy should add an opt-in checkbox
in Anaconda or firstboot.
Does anyone disagree with anything in 1-5? It all sounds reasonable to me?
Release notes are being updated as we speak. I think, the "role" of a system, be it a personal desktop, workstation, server or something else can change post-installation as well. I don't think a simple checkbox in Anaconda is going to be useful enough. We need a tool to switch policies easily so that we can tweak the policies across a wide range of tools with things like PolicyKit and each of these policies can be written with particular audiences in mind.
Rahul
I agree with 1-4 and Rahul.
--Eric
On Wed, 2009-11-18 at 20:20 -0600, Mike McGrath wrote:
- The people who want this new security policy should add an opt-in checkbox
in Anaconda or firstboot.
Does anyone disagree with anything in 1-5? It all sounds reasonable to me?
I disagree with 5, that's not a sensible or sustainable way to deal with this kind of thing. At least not without some kind of coherent process. Just throwing in single-issue checkboxes ad hoc is not the way to do this - should we have fifty checkboxes for everything you can configure users to be able to do or not able to do? If we're going to go down that route, it needs to be a properly planned utility, something like Mandriva's msec. Only, uh, probably better.
On 11/18/2009 11:27 PM, Adam Williamson wrote:
On Wed, 2009-11-18 at 20:20 -0600, Mike McGrath wrote:
- The people who want this new security policy should add an opt-in checkbox
in Anaconda or firstboot.
Does anyone disagree with anything in 1-5? It all sounds reasonable to me?
I disagree with 5, that's not a sensible or sustainable way to deal with this kind of thing. At least not without some kind of coherent process. Just throwing in single-issue checkboxes ad hoc is not the way to do this - should we have fifty checkboxes for everything you can configure users to be able to do or not able to do? If we're going to go down that route, it needs to be a properly planned utility, something like Mandriva's msec. Only, uh, probably better.
Your and Rahul's points are definitely well taken. Certainly quite a few know quite a bit more than I do, about where to put this "policy knob."
IMO #2 is the only urgent priority -- if this decision will be reverted (it should!), it should happen very soon, so that users can capture this in updates as soon after install as possible.
Jeff
On Wed, 2009-11-18 at 20:20 -0600, Mike McGrath wrote:
On Wed, 18 Nov 2009, Jeff Garzik wrote:
On 11/18/2009 07:45 PM, Mike McGrath wrote:
Stick with the facts, be clear about what you're trying to accomplish (changing it back in F13? Changing it back in F12? Setting a policy so stuff like this doesn't happen again?)
- We should recognize this new policy departs from decades of Unix and Linux
sysadmin experience.
F12 policy should be reverted to F11, ASAP. Possibly with a CVE.
Due to #1, F13+ should not deviate from the decades-old default.
Release notes should explain new [and after step #2, optional] policy in
detail, including how to turn it off again. Seth's laudable write-up efforts should not have been necessary -- that info should be prepared.
- The people who want this new security policy should add an opt-in checkbox
in Anaconda or firstboot.
Does anyone disagree with anything in 1-5? It all sounds reasonable to me?
Agree 100% with 1-4 although I would find 5 optional if PackageKit can have back the checkbox it has in F-11 to ask the user if it wants to let it "remember" the authorization. If that's not possible then either 5 or a control panel entry that let's you easily set the policy for a group, so that the system administrator can choose which users will have this privilege by adding them to a group.
Simo.
2009/11/19 Jeff Garzik jgarzik@pobox.com:
- We should recognize this new policy departs from decades of Unix and
Linux sysadmin experience.
Sure, it's different. It doesn't make it wrong.
- F12 policy should be reverted to F11, ASAP. Possibly with a CVE.
PolicyKit in F12 doesn't have the auth_admin (and save forever to disk) functionality that F11 did. I think what we have in F12 is much more usable, perhaps trading off with the perceived loss of control. I say perceived as actually typing in a root password doesn't actually make the system any more secure at all, less if anything.
- Due to #1, F13+ should not deviate from the decades-old default.
Using that argument, we can just keep using GTK tools written in python, that use consolehelper to run 2 million lines of code as the root user on the users session. How wonderful.
- Release notes should explain new [and after step #2, optional] policy in
detail, including how to turn it off again. Seth's laudable write-up efforts should not have been necessary -- that info should be prepared.
Sure, in retrospect I should have made a lot more noise in the release notes, which I apologise for. The reason people didn't notice earlier was because rawhide is unsigned, and hence all PackageKit operations required the root password, even updating.
- The people who want this new security policy should add an opt-in
checkbox in Anaconda or firstboot.
Err, I don't think this is how we want to brand the desktop spin. Other spins just need to ship different defaults for all the other PolicyKit daemons too.
Also, we've not made this change upstream lightly. We've got upstream review and policy documents which you might find useful:
http://cgit.freedesktop.org/packagekit/plain/docs/security.txt http://cgit.freedesktop.org/packagekit/plain/docs/setting-the-proxy.txt http://cgit.freedesktop.org/packagekit/plain/policy/org.freedesktop.packagek...
Richard.
On Thursday 19 November 2009 14:05:01 Richard Hughes wrote:
2009/11/19 Jeff Garzik jgarzik@pobox.com:
- We should recognize this new policy departs from decades of Unix and
Linux sysadmin experience.
Sure, it's different. It doesn't make it wrong.
- F12 policy should be reverted to F11, ASAP. Possibly with a CVE.
PolicyKit in F12 doesn't have the auth_admin (and save forever to disk) functionality that F11 did. I think what we have in F12 is much more usable, perhaps trading off with the perceived loss of control. I say perceived as actually typing in a root password doesn't actually make the system any more secure at all, less if anything.
- Due to #1, F13+ should not deviate from the decades-old default.
Using that argument, we can just keep using GTK tools written in python, that use consolehelper to run 2 million lines of code as the root user on the users session. How wonderful.
- Release notes should explain new [and after step #2, optional] policy
in detail, including how to turn it off again. Seth's laudable write-up efforts should not have been necessary -- that info should be prepared.
Sure, in retrospect I should have made a lot more noise in the release notes, which I apologise for. The reason people didn't notice earlier was because rawhide is unsigned, and hence all PackageKit operations required the root password, even updating.
- The people who want this new security policy should add an opt-in
checkbox in Anaconda or firstboot.
Err, I don't think this is how we want to brand the desktop spin. Other spins just need to ship different defaults for all the other PolicyKit daemons too.
I completely agree - other spins should select own defaults - but then you can't hide other spins but let users actual choose the right one. Instead saying - this is default spin, you should download this one, we have to state that this spin is for home desktop users, then we should have workstation spin on the same page, server spin, advanced kde desktop spin so users actually could select the correct one for their task. With website redesign - to match needs of home users - we are promoting Desktop spin as default Fedora - that's not true anymore.
Jaroslav
Also, we've not made this change upstream lightly. We've got upstream review and policy documents which you might find useful:
http://cgit.freedesktop.org/packagekit/plain/docs/security.txt http://cgit.freedesktop.org/packagekit/plain/docs/setting-the-proxy.txt http://cgit.freedesktop.org/packagekit/plain/policy/org.freedesktop.package kit.policy.in
Richard.
Once upon a time, Richard Hughes hughsient@gmail.com said:
I say perceived as actually typing in a root password doesn't actually make the system any more secure at all, less if anything.
You keep saying that, but you are wrong. Otherwise, why do we even bother with passwords (and checking password strength)?
2009/11/19 Chris Adams cmadams@hiwaay.net:
You keep saying that, but you are wrong. Otherwise, why do we even bother with passwords (and checking password strength)?
Authentication and authorisation are not the same problem at all. It's probably worth reading the PolicyKit design documents.
Richard.
Once upon a time, Richard Hughes hughsient@gmail.com said:
2009/11/19 Chris Adams cmadams@hiwaay.net:
You keep saying that, but you are wrong. Otherwise, why do we even bother with passwords (and checking password strength)?
Authentication and authorisation are not the same problem at all. It's probably worth reading the PolicyKit design documents.
I understand the difference between authentication and authorization. That still doesn't explain your assertion that requiring a restricted password is somehow less secure than not requiring a password at all.
Richard Hughes wrote:
2009/11/19 Jeff Garzik jgarzik@pobox.com:
- We should recognize this new policy departs from decades of Unix and
Linux sysadmin experience.
Sure, it's different. It doesn't make it wrong.
But the real issues which have been pointed out do.
- F12 policy should be reverted to F11, ASAP. Possibly with a CVE.
PolicyKit in F12 doesn't have the auth_admin (and save forever to disk) functionality that F11 did.
PackageKit can make remembering the authorization work without that feature. Or do you see any reason why: https://bugzilla.redhat.com/show_bug.cgi?id=534047#c141 would not work? (That said, I also blame PolicyKit for this apparently intentional regression.)
I think what we have in F12 is much more usable, perhaps trading off with the perceived loss of control.
I think you just picked the easy way out without realizing the consequences and are now spitting out bullsh*t to make us believe that decision made sense.
I say perceived as actually typing in a root password doesn't actually make the system any more secure at all, less if anything.
How is it less secure to only allow users knowing the root password (i.e. presumably the administrator(s) of the machine; if somebody else knows the root password, you have a big problem!) to install packages on their system on their own than to allow everyone and their dog to do it just because they happen to be sitting at the keyboard?
- Due to #1, F13+ should not deviate from the decades-old default.
Using that argument, we can just keep using GTK tools written in python, that use consolehelper to run 2 million lines of code as the root user on the users session. How wonderful.
That's a strawman. It wasn't his argument at all.
Err, I don't think this is how we want to brand the desktop spin. Other spins just need to ship different defaults for all the other PolicyKit daemons too.
If anything, the GNOME desktop spin should be the one customizing the policy, the default should be secure. But I don't consider this default appropriate even for that one spin.
Also, we've not made this change upstream lightly. We've got upstream review and policy documents which you might find useful:
http://cgit.freedesktop.org/packagekit/plain/docs/security.txt http://cgit.freedesktop.org/packagekit/plain/docs/setting-the-proxy.txt
http://cgit.freedesktop.org/packagekit/plain/policy/org.freedesktop.packagek...
And still you failed to realize the obvious issues with this change?
Kevin Kofler
On Fri, 2009-11-20 at 01:01 +0100, Kevin Kofler wrote:
I think what we have in F12 is much more usable, perhaps trading off with the perceived loss of control.
I think you just picked the easy way out without realizing the consequences and are now spitting out bullsh*t to make us believe that decision made sense.
Before this bit gets any nastier it's worth pointing out the initial discussion of this change:
http://thread.gmane.org/gmane.comp.freedesktop.packagekit/2611
(this is what Richard was thinking of with his passing reference to having discussed it publicly over 9 months ago. which turns out to be an underestimate :>)
On Wed, 2009-11-18 at 19:34 -0500, Jeff Garzik wrote:
IFF this feature was listed as a question in firstboot,
This is generally considered to be a bad way of organizing things. Asking people vague questions about the intended role of the system or the intended nature of a given user account is a great way to confuse them into making the wrong choice, especially since it wouldn't be at all obvious what the actual impact of each choice would be. I don't think that's the answer here. (frankly I'm a bit dubious about the plan to introduce a simplistic 'user / administrator' paradigm, but that's a wider topic).
and IFF this feature was explained in detail in release notes, then there would have been no problem at all...
it is now :) http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Note... (but yes, obviously this should have happened way before release)
You also omitted the case where admins of servers upgrade into a less secure policy. PackageKit presence does not imply desktop user.
i'm really not losing any sleep about that vector. if your server allows untrusted people to have local login access it is a badly configured server and you probably have more severe problems to worry about. the impact on _non_-server machines is more significant, to my mind.
On Wed, 2009-11-18 at 19:23 -0500, Bill Nottingham wrote:
Jeff Garzik (jgarzik@pobox.com) said:
Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions.
Out of the box, a desktop user has the ability to shut down the machine. This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want -- put viruses on
- hell, slap in a livecd or USB key and reinstall the box
It's a behavior change, for sure. For people who want to lock down their systems, it's a default they will need to be able to change, and they should have been able to discover it through the normal mechanisms for that. (i.e., the release notes.). It likely should have been discussed when it was introduced - it's obviously not something that's applicable to all usage cases for the OS.
But really, given that users out of the box can do *far far worse*, I'm not seeing the 'shameful', 'antithetical', OMG THE SKY IS FALLING AND YOU ALL SHOULD BE DRAWN AND QUARTERED sort of angst. Maybe people are tired of bagging tea and want new things to be outraged about.
Bill
Bill, You are assuming that the users have physical access to the box and also know how to get a root shell and that the box hasn't been hardened (before the PK vulnerability was known).
PackageKit is something right there on the desktop that, to its credit, needs little knowledge to use whereas many of your attack vectors noted above are generally fixed in my shop by use of a kickstart and securing the box from physical access and require a higher skill to perform.
I'm not saying this new "functionality" in PK is necessarily bad but it should have been easily ENABLED (not by default) by an admin with root privileges.
Of course, in my thought process, now, PK should probably not be installed on systems where users shouldn't have unrestricted access to the repo.
--Eric
On Wed, Nov 18, 2009 at 3:35 PM, Eric Christensen eric@christensenplace.us wrote:
PackageKit is something right there on the desktop that, to its credit, needs little knowledge to use whereas many of your attack vectors noted above are generally fixed in my shop by use of a kickstart and securing the box from physical access and require a higher skill to perform.
So can't you harden this with a kickstart file line like you do in your other hardening steps in your shop? I think to point Bill is trying to make is that there are of a number of other settings that need to be hardened and that this choice is just one of many choices associated with security associated with a console user. Console user security is already a leaky ship and PK is just one more hole.
-jef
On Wed, 2009-11-18 at 15:43 -0900, Jeff Spaleta wrote:
On Wed, Nov 18, 2009 at 3:35 PM, Eric Christensen eric@christensenplace.us wrote:
PackageKit is something right there on the desktop that, to its credit, needs little knowledge to use whereas many of your attack vectors noted above are generally fixed in my shop by use of a kickstart and securing the box from physical access and require a higher skill to perform.
So can't you harden this with a kickstart file line like you do in your other hardening steps in your shop? I think to point Bill is trying to make is that there are of a number of other settings that need to be hardened and that this choice is just one of many choices associated with security associated with a console user. Console user security is already a leaky ship and PK is just one more hole.
-jef
Maybe. I mean removing (or not installing) PK is a snap with kickstart. I haven't visited my kickstart in a while so... :)
I guess the big thing, to me, is that this vulnerability wasn't presented, documented, or talked about and it is the opposite policy to what most (all?) SYSADMINS would expect. If you don't know to fix it then you are pwned. Most of the hardening guides that I've read or have contributed to assumed that the operating system wouldn't allow this kind of behavior by default and thus doesn't really address it. I know the hardening guide for RHEL from the NSA talks about setting up sudo and how to use it but doesn't talk about securing pup, IIRC.
--Eric
On 11/18/2009 07:52 PM, Eric Christensen wrote:
I guess the big thing, to me, is that this vulnerability wasn't presented, documented, or talked about and it is the opposite policy to what most (all?) SYSADMINS would expect. If you don't know to fix it then you are pwned.
Bingo. That is the crux of the dilemma.
Jeff
On Wed, Nov 18, 2009 at 3:52 PM, Eric Christensen eric@christensenplace.us wrote:
Maybe. I mean removing (or not installing) PK is a snap with kickstart. I haven't visited my kickstart in a while so... :)
Whick PK are you talking about... packagekit or policykit? PackageKit is probably what you mean given the context..but PK as a shorthand can mean either.
And I think you missed my point. As we are learning..the hard way... sysadmins and spin developers can and should be encouraged to generate site specific policykit rules as part of hardening/softening ALL policykit enabled applications. You we really won't be able to rip out all the stuff using policykit. We're gonna have to digest the fact that policykit is there and start dealing with it in our setups and we are going to need some hand holding so we can do it effectively. PackageKit's policy is just the beginning of the learning curve here. It may not be server relevant as an application.. but the underlying issue about checking and configuring PolicyKit settings will be server relevant and unavoidable at some point.
-jef
On Wed, 2009-11-18 at 16:04 -0900, Jeff Spaleta wrote:
And I think you missed my point. As we are learning..the hard way... sysadmins and spin developers can and should be encouraged to generate site specific policykit rules as part of hardening/softening ALL policykit enabled applications. You we really won't be able to rip out all the stuff using policykit. We're gonna have to digest the fact that policykit is there and start dealing with it in our setups and we are going to need some hand holding so we can do it effectively. PackageKit's policy is just the beginning of the learning curve here. It may not be server relevant as an application.. but the underlying issue about checking and configuring PolicyKit settings will be server relevant and unavoidable at some point.
I agree, but I also agree with those who said that this issue makes it very clear we need to have some kind of process for setting a general, project-wide policy for what kind of policies packages should set via PolicyKit; this needs to be handled in a joined-up way and with the involvement of the appropriate people (i.e. the security group), not just on an ad hoc level by individual package maintainers. This should be something the FESCo discussion should cover, I think. We need to have a proper definition of our desired default security posture, and proper oversight of the implementation of this. Especially now PolicyKit usage is becoming (rightly!) widespread.
Eric Christensen (eric@christensenplace.us) said:
It's a behavior change, for sure. For people who want to lock down their systems, it's a default they will need to be able to change, and they should have been able to discover it through the normal mechanisms for that. (i.e., the release notes.). It likely should have been discussed when it was introduced - it's obviously not something that's applicable to all usage cases for the OS.
You are assuming that the users have physical access to the box and also know how to get a root shell and that the box hasn't been hardened (before the PK vulnerability was known).
Sure, I said 'out of the box'. Out of the box none of those other hardening steps are done either, which is why if this is a policy that we want, it should be documented as a hardening step that can be taken.
Bill
Bill Nottingham wrote:
Eric Christensen (eric@christensenplace.us) said:
It's a behavior change, for sure. For people who want to lock down their systems, it's a default they will need to be able to change, and they should have been able to discover it through the normal mechanisms for that. (i.e., the release notes.). It likely should have been discussed when it was introduced - it's obviously not something that's applicable to all usage cases for the OS.
You are assuming that the users have physical access to the box and also know how to get a root shell and that the box hasn't been hardened (before the PK vulnerability was known).
Sure, I said 'out of the box'. Out of the box none of those other hardening steps are done either, which is why if this is a policy that we want, it should be documented as a hardening step that can be taken.
Bill
It would seem that a middle ground could be struck here. Why not set the default to require admin privileges, and once the credentials have been established provide a check box user choice to change to the behavior that doesn't require privileges.
That way, out of the box it's a little more locked down, but easily changeable. This is a common UI pattern that you can see in many applications that have security implications... Firefox is a primary example.
Rick L Vinyard Jr wrote:
It would seem that a middle ground could be struck here. Why not set the default to require admin privileges, and once the credentials have been established provide a check box user choice to change to the behavior that doesn't require privileges.
That's exactly how Fedora 9, 10 and 11 did things. It just worked. I have no idea why this got changed.
Kevin Kofler
Verily I say unto thee, that Bill Nottingham spake thusly:
Jeff Garzik (jgarzik@pobox.com) said:
Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions.
Out of the box, a desktop user has the ability to shut down the machine. This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want -- put viruses on
- hell, slap in a livecd or USB key and reinstall the box
The desktop users on my network might have difficulty doing any of those things, since their "desktop" access is via VNC tunnelled through ssh.
However, now it seems they can arbitrarily install software into /usr, on a server that is (for some of them) in a foreign country, because of something called PackageKit.
Can you see why I might not like that situation?
It's a behavior change, for sure.
Yes. It's changed the behaviour of my server from trusted to untrusted.
For people who want to lock down their systems, it's a default they will need to be able to change
In spam terms, that's what they call "opt-out".
I don't like that much either.
and they should have been able to discover it through the normal mechanisms for that. (i.e., the release notes.).
Timely discovery of an unacceptable condition, does not somehow make that condition any more acceptable.
OMG THE SKY IS FALLING
It didn't fall. It was pushed.
Maybe people are tired of bagging tea and want new things to be outraged about.
Yes, maybe complaining about the subversion of 40 years of UNIX security is being somewhat petty.
On Thu, 2009-11-19 at 06:50 +0000, Keith G. Robertson-Turner wrote:
The desktop users on my network might have difficulty doing any of those things, since their "desktop" access is via VNC tunnelled through ssh.
However, now it seems they can arbitrarily install software into /usr, on a server that is (for some of them) in a foreign country, because of something called PackageKit.
That is incorrect, unless somehow your ssh tunneled VNC registers as "local console login", which I doubt. In your case, none of your users would be allowed to install software/updates.
Once upon a time, Jesse Keating jkeating@redhat.com said:
That is incorrect, unless somehow your ssh tunneled VNC registers as "local console login", which I doubt. In your case, none of your users would be allowed to install software/updates.
VNC looks like a local console login.
On Thu, 2009-11-19 at 10:32 -0600, Chris Adams wrote:
Once upon a time, Jesse Keating jkeating@redhat.com said:
That is incorrect, unless somehow your ssh tunneled VNC registers as "local console login", which I doubt. In your case, none of your users would be allowed to install software/updates.
VNC looks like a local console login.
Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Not according to what I'm being told by the Desktop folks, at least as far as PolicyKit and ConsoleKit are concerned.
<Oxf13> hrm, in the world of PolicyKit and ConsoleKit, does a VNC login look like a "console" login for the sake of policy? <hughsie> Oxf13: no <hughsie> if you log in, then start remote desktop, and then allow other users to connect then it does <hughsie> if you're just using vnc to create a virtual desktop for users then it's not on_console, so to speak
Verily I say unto thee, that Jesse Keating spake thusly:
On Thu, 2009-11-19 at 10:32 -0600, Chris Adams wrote:
Once upon a time, Jesse Keating jkeating@redhat.com said:
That is incorrect, unless somehow your ssh tunneled VNC registers as "local console login", which I doubt. In your case, none of your users would be allowed to install software/updates.
Thanks.
Just reading the reference material now.
Is the policy:
-constraint local
or
--constraint selinux_context:system_u:object_r:some_context_t
Is there a URL to the default PolicyKit policy shipped in F12, so I can review it?
In particular, I'm hoping to be able to re-roll the respective package to lock down the policy, then respin F12 with that modified package, for use on my network.
VNC looks like a local console login.
Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Not according to what I'm being told by the Desktop folks, at least as far as PolicyKit and ConsoleKit are concerned.
<Oxf13> hrm, in the world of PolicyKit and ConsoleKit, does a VNC login look like a "console" login for the sake of policy? <hughsie> Oxf13: no <hughsie> if you log in, then start remote desktop, and then allow other users to connect then it does <hughsie> if you're just using vnc to create a virtual desktop for users then it's not on_console, so to speak
Good. I'm doing the latter (headless server).
On Thu, 2009-11-19 at 09:02 -0800, Jesse Keating wrote:
On Thu, 2009-11-19 at 10:32 -0600, Chris Adams wrote:
Once upon a time, Jesse Keating jkeating@redhat.com said:
That is incorrect, unless somehow your ssh tunneled VNC registers as "local console login", which I doubt. In your case, none of your users would be allowed to install software/updates.
VNC looks like a local console login.
Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Not according to what I'm being told by the Desktop folks, at least as far as PolicyKit and ConsoleKit are concerned.
<Oxf13> hrm, in the world of PolicyKit and ConsoleKit, does a VNC login look like a "console" login for the sake of policy? <hughsie> Oxf13: no <hughsie> if you log in, then start remote desktop, and then allow other users to connect then it does <hughsie> if you're just using vnc to create a virtual desktop for users then it's not on_console, so to speak
however, see:
https://bugzilla.redhat.com/show_bug.cgi?id=534047#c179
which points out that one could use x11vnc to exploit this method. As x11vnc's page says:
"x11vnc allows one to view remotely and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer."
certainly seems to fit the bill. the bugzilla comment notes that a remote user could install a copy of x11vnc in his home directory and use it to gain 'local console' access, there is no need to install it systemwide.
Chris Adams (cmadams@hiwaay.net) said:
Once upon a time, Jesse Keating jkeating@redhat.com said:
That is incorrect, unless somehow your ssh tunneled VNC registers as "local console login", which I doubt. In your case, none of your users would be allowed to install software/updates.
VNC looks like a local console login.
Not as far as this authorization is concerned.
Admittedly, that could be considered a bug. (https://bugzilla.redhat.com/show_bug.cgi?id=489344)
Bill
On Thu, Nov 19, 2009 at 7:32 AM, Chris Adams cmadams@hiwaay.net wrote:
VNC looks like a local console login.
vnc setup which way? There are multiple ways to fire off a vnc session and I'd like to confirm what you are saying.
Are you using the system wide /etc/sysconfig/vncservers file provided by vnc-server in conjuction with the vncserver initscript? Or are you doing something else?
-jef
2009/11/19 Chris Adams cmadams@hiwaay.net:
Once upon a time, Jesse Keating jkeating@redhat.com said:
That is incorrect, unless somehow your ssh tunneled VNC registers as "local console login", which I doubt. In your case, none of your users would be allowed to install software/updates.
VNC looks like a local console login.
Since I am just sat logged into a F12 gnome session over vnc, I tried it:
$ geany Command not found. Install package 'geany' to provide command 'geany'? [N/y] * Installing packages.. * Getting information.. * Resolving dependencies.. * Waiting for authentication.. The transaction failed: not-authorized, Failed to obtain authentication.
This gnome session was started by logging into GDM over vnc - GDM with xdmcp enabled, and connecting from a remote machine to the VNC port via ssh forwarding.
HTH, Jonathan.
Jesse Keating wrote:
On Thu, 2009-11-19 at 06:50 +0000, Keith G. Robertson-Turner wrote:
The desktop users on my network might have difficulty doing any of those things, since their "desktop" access is via VNC tunnelled through ssh.
However, now it seems they can arbitrarily install software into /usr, on a server that is (for some of them) in a foreign country, because of something called PackageKit.
That is incorrect, unless somehow your ssh tunneled VNC registers as "local console login", which I doubt. In your case, none of your users would be allowed to install software/updates.
There is a logical flaw in this argument. Last month you would have told me the PackageKit is totally safe; you need to know the admin password to install anything. Seems that that is no longer true. Where is my guarantee that the current restrictions won't be loosened.
Le mercredi 18 novembre 2009 à 19:23 -0500, Bill Nottingham a écrit :
Out of the box, a desktop user has the ability to shut down the machine.
Well, not really anymore. If you try to press the power button now you won't get a nice software shutdown as before but an evil "do you really want to do what you've just asked me to do" popup
Really useful when X is wedged and you can't close the damn popup.
You are safe! Anyone can install anything without password, but the power button has been disabled!
Jeff et al are 100% correct - why this is even debated is unfathomable to me.
Surely it is completely obvious that the default should be off. (as it was and will be in f13+).
Why have we not got a revert fix to turn this back off in updates-testing ?
Please fix it now - then discuss how to improve the desktop experiance for Aunt tilly. But first put the security back to what it was, should be and presumably will be again anyway.
If people need it, add a button to the PK gui config tool. (WHat is it called anyway?) - I cant seem to find a [gui] config tool of any kind - maybe that should be built too before futzing with insecurity policies?
gene/
On Wed, 2009-11-18 at 23:24 -0500, Mail Llists wrote:
Jeff et al are 100% correct - why this is even debated is unfathomable to me.
Surely it is completely obvious that the default should be off. (as it was and will be in f13+).
Why have we not got a revert fix to turn this back off in updates-testing ?
Please fix it now - then discuss how to improve the desktop experiance for Aunt tilly. But first put the security back to what it was, should be and presumably will be again anyway.
If people need it, add a button to the PK gui config tool. (WHat is it called anyway?) - I cant seem to find a [gui] config tool of any kind - maybe that should be built too before futzing with insecurity policies?
Why do you assume anyone here on this thread can fix this?
Its up to the package maintainer to take a fix and ensure its well tested, pointless fire-drill exercises might make you feel better, but they don't help the distro.
Really all this bullshit in this thread, and not one patch? I think ppl prefer hearing themselves spout than actually supply a fix.
Dave.
On 11/19/2009 11:09 AM, Dave Airlie wrote:
Really all this bullshit in this thread, and not one patch? I think ppl prefer hearing themselves spout than actually supply a fix.
What patch should be supplied? It wasn't a accidental but a deliberate choice. If that choice is now considered wrong, he can very well revert it himself. No patch necessary.
Rahul
On Thu, 2009-11-19 at 15:39 +1000, Dave Airlie wrote:
Why do you assume anyone here on this thread can fix this?
Its up to the package maintainer to take a fix and ensure its well tested, pointless fire-drill exercises might make you feel better, but they don't help the distro.
Really all this bullshit in this thread, and not one patch? I think ppl prefer hearing themselves spout than actually supply a fix.
I don't think it's a question of supplying a patch. It's not a code deficiency, it's a conscious policy choice. The maintainer knows perfectly well how to change the policy - after all, that's what he did in the first place. It's not that he's just waiting on a patch, that's not the issue here.
Jeff Garzik wrote:
Even Microsoft Windows asks for elevated privileges for this sort of thing!
What I'd like to have is a comprehensive set of options that need to be locked down in PolicyKit to get a secure system. It looks like there are tons of potentially nasty options enabled by default, with little information over what they do.
What does org.freedesktop.devicekit.disks.filesystem-mount do? Does this mean a console user can mount any file system, even non- removable media?
Does org.fedoraproject.abrt.install-debuginfos mean that any console user can fill up the root partition with debuginfo rpms?
Does org.freedesktop.RealtimeKit1.acquire-high-priority mean that any console user can stop the rest of the system working by opening up lots of realtime processes?
Who knows what org.freedesktop.devicekit.disks.change, “Modify a device” does. Sounds nasty.
Can the user detach a system disk? org.freedesktop.devicekit.disks.drive- detach
or start a fsck? org.freedesktop.devicekit.disks.filesystem-check
I don't mind users being able to handle removable media, but I don't want them messing around as sysadmin on system disks, changing timezones, etc...
Where is all this explained?
Jeremy
On 11/19/2009 03:38 PM, Jeremy Sanders wrote:
Jeff Garzik wrote:
Even Microsoft Windows asks for elevated privileges for this sort of thing!
What I'd like to have is a comprehensive set of options that need to be locked down in PolicyKit to get a secure system. It looks like there are tons of potentially nasty options enabled by default, with little information over what they do.
http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Note...
Man page:
pklocalauthority(8) polkit(8) polkitd(8) pkaction(1), pkcheck(1), pkexec(1)
Rahul
Rahul Sundaram wrote:
http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-
Release_Notes-Security.html
Man page:
pklocalauthority(8) polkit(8) polkitd(8) pkaction(1), pkcheck(1), pkexec(1)
Which of these documents actually explains what these options do properly? I couldn't see anything.
They just print out vague descriptions and are not comprehensive. Most of the documentation just tells me how the configuration files are formatted.
The sysadmin has no way of verifying exactly what these options do.
How do I know nobody is going to add another option mid way through a fedora cycle or with no documentation I need to be aware of?
Jeremy
On 11/19/2009 03:48 PM, Jeremy Sanders wrote:
Which of these documents actually explains what these options do properly? I couldn't see anything.
They just print out vague descriptions and are not comprehensive. Most of the documentation just tells me how the configuration files are formatted.
The sysadmin has no way of verifying exactly what these options do.
How do I know nobody is going to add another option mid way through a fedora cycle or with no documentation I need to be aware of?
The release notes give a specific example that retains a locked down environment. polkit man has many details as well. If you need improvements, feel free to file bug reports. I just pointed out what is available.
Rahul
On 11/18/2009 03:27 PM, Seth Vidal wrote:
2009/11/18 nodata lsof@nodata.co.uk:
Am 2009-11-18 20:20, schrieb Richard Hughes:
2009/11/18 Casey Dahlincdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo!
If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it.
So here is what I've just gotten from talking to Ray Strode and reading docs.
if you want to disable this just run:
pklalockdown --lockdown org.freedesktop.packagekit.package-install
that will keep anyone from installing pkgs w/o authenticating as admin.
That's the short version.
the long version I'm working on writing up right now.
-sv
Thanks for this Seth
TK009
On Wed, Nov 18, 2009 at 19:20:42 +0000, Richard Hughes hughsient@gmail.com wrote:
2009/11/18 Casey Dahlin cdahlin@redhat.com:
By the admin's first opportunity to change the settings the box could already be rooted.
I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine.
The person may not intentionally be attacking the machine, they may just install something that is vulnerable without the approval of the administrator.
Am 2009-11-18 19:14, schrieb Rahul Sundaram:
On 11/18/2009 11:44 PM, Bruno Wolff III wrote:
Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems.
This assumes the user is different from a admin, which is not true for a personal desktop. This revolves back to what the default target audience should be. PackageKit target audience is defined at
http://www.packagekit.org/pk-profiles.html
If it doesn't match what Fedora wants, then it should be tweaked but the larger question should be addressed first.
Rahul
Rahul, it seems to be that the person who made this change (fesco approved?) is the one who should answer why the change is a good thing, rather than "oh I changed it, now tell me why it's bad". Do you know who it was?
On 11/19/2009 12:31 AM, nodata wrote:
Rahul, it seems to be that the person who made this change (fesco approved?) is the one who should answer why the change is a good thing, rather than "oh I changed it, now tell me why it's bad". Do you know who it was?
I don't see why FESCo should be involved and I have no idea who made this decision. I would have preferred the change to be announced and documented in detail regardless of that. I assume David Zeuthen? (CC'ed)
Rahul
On Thu, 2009-11-19 at 00:34 +0530, Rahul Sundaram wrote:
On 11/19/2009 12:31 AM, nodata wrote:
Rahul, it seems to be that the person who made this change (fesco approved?) is the one who should answer why the change is a good thing, rather than "oh I changed it, now tell me why it's bad". Do you know who it was?
I don't see why FESCo should be involved and I have no idea who made this decision. I would have preferred the change to be announced and documented in detail regardless of that. I assume David Zeuthen? (CC'ed)
Jeez, Rahul. This has nothing to do with polkit per se, only PackageKit and how it decides to use polkit. I've commented that much in the bug. And as noted in the bug I don't even agree there's a problem. But I leave that to Richard and others to sort out.
Btw, please don't add me to the Cc again like this or reply to this - I'm not interested in this bike-shed or what color it is. Thanks.
David
On 11/19/2009 01:26 AM, David Zeuthen wrote:
On Thu, 2009-11-19 at 00:34 +0530, Rahul Sundaram wrote:
On 11/19/2009 12:31 AM, nodata wrote:
Rahul, it seems to be that the person who made this change (fesco approved?) is the one who should answer why the change is a good thing, rather than "oh I changed it, now tell me why it's bad". Do you know who it was?
I don't see why FESCo should be involved and I have no idea who made this decision. I would have preferred the change to be announced and documented in detail regardless of that. I assume David Zeuthen? (CC'ed)
Jeez, Rahul. This has nothing to do with polkit per se, only PackageKit and how it decides to use polkit.
Well, your reaction sounds like, everybody is expected to know this automatically. It is clear to me, that is not the case. So let's not overreact.
Rahul
David Zeuthen wrote:
Jeez, Rahul. This has nothing to do with polkit per se, only PackageKit and how it decides to use polkit.
Yet the root of the problem seems to be that in PolicyKit 1, you dropped support for the auth_admin_keep_always feature which was used so far and which had exactly the semantics we want.
See: https://fedorahosted.org/fesco/ticket/277#comment:4 and this is confirmed by yourself here: http://lists.freedesktop.org/archives/polkit-devel/2009-September/000213.htm...
Kevin Kofler
On Wed, 18 Nov 2009, Bruno Wolff III wrote:
On Wed, Nov 18, 2009 at 23:18:28 +0530, Rahul Sundaram sundaram@fedoraproject.org wrote:
On 11/18/2009 11:19 PM, nodata wrote:
Thanks. I have changed the title to: "All users get to install software on a machine they do not have the root password to"
.. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail.
Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems.
If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case.
-sv
On Wed, Nov 18, 2009 at 13:22:03 -0500, Seth Vidal skvidal@fedoraproject.org wrote:
If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case.
There definitely is some user oriented stuff that gets run by default, but maybe only when using a desktop. Bluetooth seems to work that way. Installing beagle and another indexing program I noticed recently but don't remember the name of, schedule indexing operations by default. There is a mail client that has an annoying desktop popup by the default just for having it installed. There are other things that are needed for lots of stuff to function, such as pulseaudio, so it's not always clear cut what the proper default should be.
[At the risk of letting this get lost in the shuffle of this thread...]
Seth Vidal wrote:
If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case.
I happened to install func the other day on several Fedora and CentOS boxes and was surprised that both services defaulted to on.
Trying this on clean Fedora 12 box I found that a combination of a poor init script and the presence of redhat-lsb had prevented the services from being configured as the packages intend them to be:
$ sudo yum install certmaster ... $ sudo chkconfig --list certmaster service certmaster supports chkconfig, but is not referenced in any runlevel (run 'chkconfig --add certmaster')
The problem is that %post checks first for the presence of /usr/lib/lsb/install_initd, which redhat-lsb provides:
# for suse if [ -x /usr/lib/lsb/install_initd ]; then /usr/lib/lsb/install_initd /etc/init.d/funcd # for red hat distros elif [ -x /sbin/chkconfig ]; then /sbin/chkconfig --add funcd ... fi
Fortunately, neither funcd nor certmaster provide critical things like, say, remote control of a system. ;)
On 11/18/2009 08:22 PM, Todd Zullinger wrote:
[At the risk of letting this get lost in the shuffle of this thread...]
Seth Vidal wrote:
If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case.
I happened to install func the other day on several Fedora and CentOS boxes and was surprised that both services defaulted to on.
Please file a bug here.
~spot
Tom spot Callaway wrote:
I happened to install func the other day on several Fedora and CentOS boxes and was surprised that both services defaulted to on.
Please file a bug here.
I do intend to, just hadn't gotten to it yet. :)
Seth Vidal skvidal@fedoraproject.org writes:
If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case.
Is there a blanket prohibition on daemons defaulting to ON or are some (presumably considered vital) daemons exempt? I ask because cronie defaults to ON.
/Benny
Benny Amorsen (benny+usenet@amorsen.dk) said:
If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case.
Is there a blanket prohibition on daemons defaulting to ON or are some (presumably considered vital) daemons exempt? I ask because cronie defaults to ON.
It's not a blanket prohibition. (See also opensshd, rsyslog, etc.)
Bill
On Fri, 2009-11-20 at 10:50 -0500, Bill Nottingham wrote:
Benny Amorsen (benny+usenet@amorsen.dk) said:
If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case.
Is there a blanket prohibition on daemons defaulting to ON or are some (presumably considered vital) daemons exempt? I ask because cronie defaults to ON.
It's not a blanket prohibition. (See also opensshd, rsyslog, etc.)
Additionally, I believe it applies only to daemons which are configured to be remote-accessible by default. I don't believe cronie is.
On Fri, 20 Nov 2009, Bill Nottingham wrote:
Benny Amorsen (benny+usenet@amorsen.dk) said:
If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case.
Is there a blanket prohibition on daemons defaulting to ON or are some (presumably considered vital) daemons exempt? I ask because cronie defaults to ON.
It's not a blanket prohibition. (See also opensshd, rsyslog, etc.)
IOW, a typical user really has no idea what "install signed fedora packages" means in terms of security.
It doesn't matter how good the GUI looks and operates if people can't understand what it means.
- James
On Wed, 2009-11-18 at 23:18 +0530, Rahul Sundaram wrote:
On 11/18/2009 11:19 PM, nodata wrote:
Thanks. I have changed the title to: "All users get to install software on a machine they do not have the root password to"
.. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail.
That is important, and personally I have a lot of sympathy for some of the desired use cases¹ I've heard about. On the other hand this does open up a lot of ways to attack the system, esp. given that there is _no_ authentication ... as I had expected that code running as the user would still have to authenticate as the user (Hello Linux virus makers, welcome to the party). Off the top of my head, these are the first things I'd look at for attacking a system with PK and this config:
1. Does "install" of obsoleting packages come under the same auth. (if so I can now arbitrarily upgrade certain packages).
2. Does "install" of installonly come under the same auth. (if so I can now stop kernel upgrades).
3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop.
4. Are there any attacks against packages with "default on" services? (Note that you can almost certainly wait until there is an attack, and then install the insecure service).
5. Are there any attacks against packages with set*id apps? (Dito. with the waiting approach in #4).
6. Are there any attacks against packages which provide plugins? (Dito. waiting)
7. And the most obvious one ... how hard is it to get a bad package into one of the repos. that the machine has enabled.
¹ Things like letting a spouse/child install a new game/theme/editor/etc. without having to get "their admin" to do it.
² If /var is on a separate partition then spamming /var/tmp is a goood first step here.
On Wed, 18 Nov 2009, James Antill wrote:
- Does "install" of obsoleting packages come under the same auth. (if
so I can now arbitrarily upgrade certain packages).
- Does "install" of installonly come under the same auth. (if so I can
now stop kernel upgrades).
+1
- Are there any attacks against packages with "default on" services?
(Note that you can almost certainly wait until there is an attack, and then install the insecure service).
And if we have default on services then I think we should take a good LOOOOOOOOOONG look at them.
- And the most obvious one ... how hard is it to get a bad package into
one of the repos. that the machine has enabled.
+many
-sv
On Wed, 2009-11-18 at 13:22 -0500, James Antill wrote:
- And the most obvious one ... how hard is it to get a bad package into
one of the repos. that the machine has enabled.
Right, PK is counting on this being sufficiently difficult enough to prevent bad things from happening. While I'd like to think that, and would like to say that, I can't.
On Wed, 2009-11-18 at 10:52 -0800, Jesse Keating wrote:
On Wed, 2009-11-18 at 13:22 -0500, James Antill wrote:
- And the most obvious one ... how hard is it to get a bad package into
one of the repos. that the machine has enabled.
Right, PK is counting on this being sufficiently difficult enough to prevent bad things from happening. While I'd like to think that, and would like to say that, I can't.
I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see.
On Wed, 2009-11-18 at 14:49 -0800, Adam Williamson wrote:
On Wed, 2009-11-18 at 10:52 -0800, Jesse Keating wrote:
On Wed, 2009-11-18 at 13:22 -0500, James Antill wrote:
- And the most obvious one ... how hard is it to get a bad package into
one of the repos. that the machine has enabled.
Right, PK is counting on this being sufficiently difficult enough to prevent bad things from happening. While I'd like to think that, and would like to say that, I can't.
I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
I'd like to point out that there are trusted packages that I wouldn't want my users downloading. John is a good example but there are others.
Anyone requested that CVE yet?
--Eric
On Wed, 2009-11-18 at 17:54 -0500, Eric Christensen wrote:
I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see.
I'd like to point out that there are trusted packages that I wouldn't want my users downloading. John is a good example but there are others.
Anyone requested that CVE yet?
That's a different point, and specifically _not_ the point I was addressing. You don't need to point it out as it's already been pointed out about five times earlier in the thread. :)
Adam Williamson awilliam@redhat.com writes:
I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see.
Really? You are talking about changing "the local administrator trusts *this* package" to "the local administrator trusts whoever has the signing key for Fedora to decide which packages should be installed".
On 11/18/2009 01:22 PM, James Antill wrote:
- Are there any attacks due to disk space used? Eg. If /var is low² I
can probably install enough pkgs to make logging stop.
I'm betting there's still enough systems out there without enough space in /usr for the entire package set.
--CJD
2009/11/18 Casey Dahlin cdahlin@redhat.com:
On 11/18/2009 01:22 PM, James Antill wrote:
- Are there any attacks due to disk space used? Eg. If /var is low² I
can probably install enough pkgs to make logging stop.
I'm betting there's still enough systems out there without enough space in /usr for the entire package set.
That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, <swap>, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install.
Regards,
On Wed, 18 Nov 2009, Konstantin Ryabitsev wrote:
2009/11/18 Casey Dahlin cdahlin@redhat.com:
On 11/18/2009 01:22 PM, James Antill wrote:
- Are there any attacks due to disk space used? Eg. If /var is low² I
can probably install enough pkgs to make logging stop.
I'm betting there's still enough systems out there without enough space in /usr for the entire package set.
That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, <swap>, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install.
well - except for the 5% reserved for root :)
-sv
On 11/18/2009 02:10 PM, Seth Vidal wrote:
On Wed, 18 Nov 2009, Konstantin Ryabitsev wrote:
2009/11/18 Casey Dahlin cdahlin@redhat.com:
On 11/18/2009 01:22 PM, James Antill wrote:
- Are there any attacks due to disk space used? Eg. If /var is low² I
can probably install enough pkgs to make logging stop.
I'm betting there's still enough systems out there without enough space in /usr for the entire package set.
That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, <swap>, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install.
well - except for the 5% reserved for root :)
-sv
Which isn't safe from this since ultimately its root doing the install on the unprivileged user's behalf.
--CJD
On Wed, 18 Nov 2009, Casey Dahlin wrote:
On 11/18/2009 02:10 PM, Seth Vidal wrote:
On Wed, 18 Nov 2009, Konstantin Ryabitsev wrote:
2009/11/18 Casey Dahlin cdahlin@redhat.com:
On 11/18/2009 01:22 PM, James Antill wrote:
- Are there any attacks due to disk space used? Eg. If /var is low² I
can probably install enough pkgs to make logging stop.
I'm betting there's still enough systems out there without enough space in /usr for the entire package set.
That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, <swap>, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install.
well - except for the 5% reserved for root :)
-sv
Which isn't safe from this since ultimately its root doing the install on the unprivileged user's behalf.
which is why I said the user filling up /tmp couldn't fill up the whole disk..
-sv
Once upon a time, Rahul Sundaram sundaram@fedoraproject.org said:
.. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail.
Fedora has made a big push into the multi-user desktop (which many home computers are now) with things like fast user switching. In many such setups, not all users are considered "administrators" of the system (think parents and kids for example). However, Fedora continues to slip in (with no announcement and no documentation on how to change) things that allow the console user to be an administrator without any additional authentication.
The answer here has been "well root should lock it down". With the ever-increasing complexity of the system, it is becoming more difficult than ever to find (or even know about) all of the ways a system musth be locked down. "find / -perm +6000" doesn't cut it anymore, but there's no documentation of all the ways a regular user can do administrative tasks without an administrative password.
It seems the latest way of doing this is via PolicyKit. IMHO all PolicyKit configuration should be "secure by default", and then desktop spins can include overrides in /etc to loosen-up security where desired. This would also make it much easier to find and clearer to see what might should be changed for local policy.
Right now, I see files /usr/share/PolicyKit/policy; I guess that's where this kind of thing comes from. How do I override the settings in one of these files? None of them are marked "config", so I guess I don't edit them. Are there other places such policy can be set?
On Wed, Nov 18, 2009 at 1:48 PM, Chris Adams cmadams@hiwaay.net wrote:
It seems the latest way of doing this is via PolicyKit. IMHO all PolicyKit configuration should be "secure by default",
"secure" is an meaningless term without reference to a deployment model and threat model, but let's assume here for reference that what you mean is that the shipped RPMs should be configured to not grant any additional privileges over that afforded to the traditional Unix timesharing model, and then the desktop kickstart modifies them.
I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping?
Right now, I see files /usr/share/PolicyKit/policy; I guess that's where this kind of thing comes from. How do I override the settings in one of these files? None of them are marked "config", so I guess I don't edit them. Are there other places such policy can be set?
See "man PolicyKit.conf"
On Wed, 2009-11-18 at 14:11 -0500, Colin Walters wrote:
I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping?
It seem obvious we are talking only about this specific behavior of PackageKit at the moment.
Now if it were at least *easy* to revert this behavior ... Take a default F-12 and without much knowledge try to change it (like I would want to do if I had kids).
Simo.
Once upon a time, Colin Walters walters@verbum.org said:
On Wed, Nov 18, 2009 at 1:48 PM, Chris Adams cmadams@hiwaay.net wrote:
It seems the latest way of doing this is via PolicyKit. Â IMHO all PolicyKit configuration should be "secure by default",
"secure" is an meaningless term without reference to a deployment model and threat model, but let's assume here for reference that what you mean is that the shipped RPMs should be configured to not grant any additional privileges over that afforded to the traditional Unix timesharing model, and then the desktop kickstart modifies them.
Yes, that was what I meant.
I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping?
In an ideal world, everything that could grant elevated privilege would come without it, and the admin (or spin config files) could easily configure it back.
That obviously fails for things like /bin/ping, since that uses file permissions, and that's part of the RPM (and not configurable). However, ping has traditionally been run-able as a non-root user, and it is easily spotted with find. The number of setuid programs is small these days, but several of them are now "helpers" that allow a wide-range of other programs access, again with minimal documentation (what is pulse/proximity-helper? why is nspluginwrapper/plugin-config setuid root?)
I think anything that uses PolicyKit should ship with no elevated privileges by default, since it is configurable.
It would be nice to also get consolehelper, but that is more complicated. I thought that was on the way out (to be replaced by PolicyKit), but I see there are still a number of things that use it (looking at the F11 desktop I'm on right now).
NetworkManager is another thing that probably could use some admin control in some places, especially as it is being pushed to replace the old network scripts. Does NM use PolicyKit or consolehelper, or does it just do things itself?
Right now, I see files /usr/share/PolicyKit/policy; I guess that's where this kind of thing comes from. Â How do I override the settings in one of these files? Â None of them are marked "config", so I guess I don't edit them. Â Are there other places such policy can be set?
See "man PolicyKit.conf"
The bigger issue is that much of the policy is not well documented, except in the XML files (which are pretty terse).
On Wed, 2009-11-18 at 13:31 -0600, Chris Adams wrote:
Once upon a time, Colin Walters walters@verbum.org said:
On Wed, Nov 18, 2009 at 1:48 PM, Chris Adams cmadams@hiwaay.net wrote:
It seems the latest way of doing this is via PolicyKit. Â IMHO all PolicyKit configuration should be "secure by default",
"secure" is an meaningless term without reference to a deployment model and threat model, but let's assume here for reference that what you mean is that the shipped RPMs should be configured to not grant any additional privileges over that afforded to the traditional Unix timesharing model, and then the desktop kickstart modifies them.
Yes, that was what I meant.
I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping?
In an ideal world, everything that could grant elevated privilege would come without it, and the admin (or spin config files) could easily configure it back.
That obviously fails for things like /bin/ping, since that uses file permissions, and that's part of the RPM (and not configurable). However, ping has traditionally been run-able as a non-root user, and it is easily spotted with find. The number of setuid programs is small these days, but several of them are now "helpers" that allow a wide-range of other programs access, again with minimal documentation (what is pulse/proximity-helper? why is nspluginwrapper/plugin-config setuid root?)
I think anything that uses PolicyKit should ship with no elevated privileges by default, since it is configurable.
It would be nice to also get consolehelper, but that is more complicated. I thought that was on the way out (to be replaced by PolicyKit), but I see there are still a number of things that use it (looking at the F11 desktop I'm on right now).
NetworkManager is another thing that probably could use some admin control in some places, especially as it is being pushed to replace the old network scripts. Does NM use PolicyKit or consolehelper, or does it just do things itself?
It uses PolicyKit. We have a bit of work to do before we have fine-grained lockdown, but it's not that far off. F13 perhaps? It's basically a case of defining the permissions (there are already a few for things like disallowing modification of system connections, disabling the "create new network" functionality, etc) and then making sure NM checks them, and *also* making sure the UI provides appropriate feedback when something is not allowed at all, as opposed to "allowed if you authenticate first".
Dan
Right now, I see files /usr/share/PolicyKit/policy; I guess that's where this kind of thing comes from. Â How do I override the settings in one of these files? Â None of them are marked "config", so I guess I don't edit them. Â Are there other places such policy can be set?
See "man PolicyKit.conf"
The bigger issue is that much of the policy is not well documented, except in the XML files (which are pretty terse). -- Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Wed, Nov 18, 2009 at 13:31:49 -0600, Chris Adams cmadams@hiwaay.net wrote:
(what is pulse/proximity-helper? why is nspluginwrapper/plugin-config setuid root?)
I already filed a bug (491543) about that. It does bad things, but the maintainer doesn't seem to want to change it.
Firefox reenables disabled plugins. So you pretty much have to uninstall any that you don't want it to use.
(Thanks for a constructive discussion by the way!)
David, added you to CC for a question below:
On Wed, Nov 18, 2009 at 2:31 PM, Chris Adams cmadams@hiwaay.net wrote:
I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping?
In an ideal world, everything that could grant elevated privilege would come without it, and the admin (or spin config files) could easily configure it back.
Right.
That obviously fails for things like /bin/ping, since that uses file permissions, and that's part of the RPM (and not configurable). However, ping has traditionally been run-able as a non-root user, and it is easily spotted with find.
Right; I gave the specific example of ping because it's about the oldest most "traditional Unix" thing I could think of.
The number of setuid programs is small these days, but several of them are now "helpers" that allow a wide-range of other programs access, again with minimal documentation (what is pulse/proximity-helper? why is nspluginwrapper/plugin-config setuid root?)
Hm, this is off the top of my head, but I think the idea with nspluginwrapper is that you install the flash-plugin RPM (which has no idea about nspluginwrapper, and I think upstream is actively hostile to it actually), then restart firefox (as your user), but the installed flash plugin needs to be wrapped, so our firefox runs the setuid script to update the system plugin database.
Not sure about proximity.
Yes, we could clearly use more auditing here.
I think anything that uses PolicyKit should ship with no elevated privileges by default, since it is configurable.
So, that leaves us with the question of how to configure it for Fedora. A data point here is that the Fedora polkit package adds two Unix groups "desktop_user_r" and "desktop_admin_r". However, it's unclear to me whether the expectation is that official Fedora consumables (i.e. desktop installer) would customize PolicyKit using these.
David, what do you think about having Fedora RPMs have all defaults be "no"? And getting this change made upstream? We discussed this eariler, you replied here:
http://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00266.html
Do you still advocate "doing this is achieved simply by editing PolicyKit.conf in the %post of the live cd creator. It's that simple really." ?
We need to have some "story" for this, otherwise it's really confusing to everyone, from developers to admins, see e.g.:
http://www.redhat.com/archives/rhl-devel-list/2009-August/msg00578.html
It would be nice to also get consolehelper, but that is more complicated. I thought that was on the way out (to be replaced by PolicyKit), but I see there are still a number of things that use it (looking at the F11 desktop I'm on right now).
Yeah, converting system-config- is going to take some time.
The bigger issue is that much of the policy is not well documented, except in the XML files (which are pretty terse).
The individual actions aren't documented well enough? Or the 1,000 meter view of all of the installed actions on a default desktop?
Once upon a time, Colin Walters walters@verbum.org said:
(Thanks for a constructive discussion by the way!)
No problem; I'm trying to understand and help things move forward. I don't want to see another thing like SELinux or PulseAudio where it becomes "common knowledge" that you should just disable or remove something.
So, that leaves us with the question of how to configure it for Fedora. A data point here is that the Fedora polkit package adds two Unix groups "desktop_user_r" and "desktop_admin_r". However, it's unclear to me whether the expectation is that official Fedora consumables (i.e. desktop installer) would customize PolicyKit using these.
Where are those documented? I guess that's something new for F12, so maybe there's something there. However, I just searched the Fedora wiki and got no hits (if this is Fedora-specific, shouldn't it be there?).
The bigger issue is that much of the policy is not well documented, except in the XML files (which are pretty terse).
The individual actions aren't documented well enough? Or the 1,000 meter view of all of the installed actions on a default desktop?
I guess some of both. At a quick glance, I see over 100 actions on my F11 desktop (in over 1400 lines of XML, not counting langauges); how am I supposed to be knowledgeable enough to know which of those I may want (or need) to change for certain situations? Don't get me wrong; I do like having more fine-grained access control.
What would be nice would be a guide of how all this fits together and when to change what (not just documentation of individual options or syntax), but I do also understand that developers don't always like writing documentation (hey, who does, other than tech writers!).
On Wed, 2009-11-18 at 14:39 -0600, Chris Adams wrote:
What would be nice would be a guide of how all this fits together and when to change what (not just documentation of individual options or syntax), but I do also understand that developers don't always like writing documentation (hey, who does, other than tech writers!).
In this case we do have some documentation. man 8 polkit looks to be a great read for getting your head around this stuff. Unfortunately you need to be on an F12 box (or chroot) to run that, although the man page may be on the web somewhere.
On Wed, 18 Nov 2009, Jesse Keating wrote:
On Wed, 2009-11-18 at 14:39 -0600, Chris Adams wrote:
What would be nice would be a guide of how all this fits together and when to change what (not just documentation of individual options or syntax), but I do also understand that developers don't always like writing documentation (hey, who does, other than tech writers!).
In this case we do have some documentation. man 8 polkit looks to be a great read for getting your head around this stuff. Unfortunately you need to be on an F12 box (or chroot) to run that, although the man page may be on the web somewhere.
polkit man page tells you a lot - but it's not going to help a sysadmin configure something TODAY. FAQs and HOWTOs will do that.
-sv
On Wed, Nov 18, 2009 at 02:11:18PM -0500, Colin Walters wrote:
On Wed, Nov 18, 2009 at 1:48 PM, Chris Adams cmadams@hiwaay.net wrote:
It seems the latest way of doing this is via PolicyKit. IMHO all PolicyKit configuration should be "secure by default",
"secure" is an meaningless term without reference to a deployment model and threat model,
Chris gave you such a model:
On Wed, Nov 18, 2009 at 1:48 PM, Chris Adams cmadams@hiwaay.net wrote:
Fedora has made a big push into the multi-user desktop (which many home computers are now) with things like fast user switching. In many such setups, not all users are considered "administrators" of the system (think parents and kids for example). However, Fedora continues to slip in (with no announcement and no documentation on how to change) things that allow the console user to be an administrator without any additional authentication.
Rich.
On Wed, Nov 18, 2009 at 11:18:28PM +0530, Rahul Sundaram wrote:
On 11/18/2009 11:19 PM, nodata wrote:
Thanks. I have changed the title to: "All users get to install software on a machine they do not have the root password to"
.. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail.
They can install a package with a known local root exploit?
They can install lots of packages are fill up all the disk space?
They can install commands that the owner of the machine doesn't want?
Rich.
Or even ..
They become a Fedora packager, they put a backdoor into a Fedora package (which is very discrete and is only triggered when $hostname = $targethost), and they install that.
Rich.
On Wed, 2009-11-18 at 20:00 +0000, Richard W.M. Jones wrote:
They can install lots of packages are fill up all the disk space?
Has someone checked yet whether this is actually possible? There are nuances here. It depends whether PackageKit is capable of using up the space reserved for root when installing packages or not. Even if it's operating 'as root', it doesn't necessarily follow that it can, as I understand it. Please check this before asserting it.
On Wednesday 18 November 2009 12:48:28 pm Rahul Sundaram wrote:
.. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail.
Not every Fedora installation will fall neatly into "single user" or "actively managed" categories. I might be managing half a dozen machines in some office at my university, and had I not known about this new, unprecedented feature, I might come in one day and discover that everyone is running a completely different system -- even though none of them have the root password! I also cannot claim that I am familiar with all of the thousands of packages in the Fedora repositories, and would rather not come in one day and have a user ask me for help after having installed dozens of unfamiliar packages after a few weeks of using the system.
I do not feel this is a terribly contrived example...
-- Ben
On Wed, Nov 18, 2009 at 11:18:28PM +0530, Rahul Sundaram wrote:
On 11/18/2009 11:19 PM, nodata wrote:
Thanks. I have changed the title to: "All users get to install software on a machine they do not have the root password to"
.. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail.
To me it looks like the F12 i386 Everything repository is not signed: $ curl -sI http://download.fedoraproject.org/pub/fedoralinux/releases/12/Everything/i38... | head -n1 HTTP/1.1 404 NOT FOUND
So at least one major security protection measure is not in place and attackers can create their own repositories with signed packages that have well known security flaws, e.g. a package with a bad setuid root binary, and install it, if it is not already installed in a newer version.
Regards Till
On 2009-11-19 10:23:53 AM, Till Maas wrote:
So at least one major security protection measure is not in place and attackers can create their own repositories with signed packages that have well known security flaws, e.g. a package with a bad setuid root binary, and install it, if it is not already installed in a newer version.
I might be wrong on this, but wouldn't the attacker need to trick yum/packagekit into using the malicious repo first? I didn't think that was allowed for non-root users.
Note that even if the repomd.xml files were signed, it'd be easy for an attacker to just take an old one with a valid signature and host a repo with outdated packages. I thought metalink (https://mirrors.fedoraproject.org/metalink?repo=updates-released-f12&arc...) over https was supposed to address the problem of outdated repos though.
Thanks, Ricky
On Thu, Nov 19, 2009 at 04:36:27AM -0500, Ricky Zhou wrote:
On 2009-11-19 10:23:53 AM, Till Maas wrote:
So at least one major security protection measure is not in place and attackers can create their own repositories with signed packages that have well known security flaws, e.g. a package with a bad setuid root binary, and install it, if it is not already installed in a newer version.
I might be wrong on this, but wouldn't the attacker need to trick yum/packagekit into using the malicious repo first? I didn't think that was allowed for non-root users.
Yes packagekit must be tricked into using the malicious repo, but this is not something that needs to be done on the system, but can also be done by an MITM attack on the network traffic or compromising DNS.
Note that even if the repomd.xml files were signed, it'd be easy for an attacker to just take an old one with a valid signature and host a repo with outdated packages. I thought metalink (https://mirrors.fedoraproject.org/metalink?repo=updates-released-f12&arc...) over https was supposed to address the problem of outdated repos though.
It seems that at least the information provided in the metalink is enough to perform proper verification and deny outdated repositories, since there are timestamps and secure hashes provided for the repomd.xml file. But there might be still a problem with third party repositories, if they do not use metalink. And if the metalink information is not used in a secure way by yum.
Regards Till
Once upon a time, Ricky Zhou ricky@fedoraproject.org said:
I might be wrong on this, but wouldn't the attacker need to trick yum/packagekit into using the malicious repo first? I didn't think that was allowed for non-root users.
1.5 words: NetworkManager. Think about it.
2009/11/19 Chris Adams cmadams@hiwaay.net:
Once upon a time, Ricky Zhou ricky@fedoraproject.org said:
I might be wrong on this, but wouldn't the attacker need to trick yum/packagekit into using the malicious repo first? I didn't think that was allowed for non-root users.
1.5 words: NetworkManager. Think about it.
2 words: Package signing.
If the key is different to the one that was preciously imported, you need the root password.
Richard.
Once upon a time, Richard Hughes hughsient@gmail.com said:
2009/11/19 Chris Adams cmadams@hiwaay.net:
Once upon a time, Ricky Zhou ricky@fedoraproject.org said:
I might be wrong on this, but wouldn't the attacker need to trick yum/packagekit into using the malicious repo first? I didn't think that was allowed for non-root users.
1.5 words: NetworkManager. Think about it.
2 words: Package signing.
If the key is different to the one that was preciously imported, you need the root password.
2 words: replay attack.
So there are no packages in releases/12/Everything that have privilege escalation bugs? All I have to do is wait for one to be found, and I have a signed path to root. Even if the package is fixed in updates, I just have to have a custom updates repo without it.
2009/11/19 Chris Adams cmadams@hiwaay.net:
So there are no packages in releases/12/Everything that have privilege escalation bugs? All I have to do is wait for one to be found, and I have a signed path to root. Even if the package is fixed in updates, I just have to have a custom updates repo without it.
No, that won't work either. In PackageKit parlance "installing a package" is installing a package that does not already exist on the computer. You can't downgrade (or upgrade) packages using the PackageKit InstallPackages() method.
Richard.
Hi.
On Thu, 19 Nov 2009 14:39:13 +0000, Richard Hughes wrote:
No, that won't work either. In PackageKit parlance "installing a package" is installing a package that does not already exist on the computer. You can't downgrade (or upgrade) packages using the PackageKit InstallPackages() method.
So I could install a package without a password, but I could not update one? That would be weird, to say the least.
Once upon a time, Richard Hughes hughsient@gmail.com said:
2009/11/19 Chris Adams cmadams@hiwaay.net:
So there are no packages in releases/12/Everything that have privilege escalation bugs? All I have to do is wait for one to be found, and I have a signed path to root. Even if the package is fixed in updates, I just have to have a custom updates repo without it.
No, that won't work either. In PackageKit parlance "installing a package" is installing a package that does not already exist on the computer. You can't downgrade (or upgrade) packages using the PackageKit InstallPackages() method.
That only matters if you install every package in the repo, which I don't think many people do.
On 11/18/2009 06:14 PM, Rahul Sundaram wrote:
On 11/18/2009 10:38 PM, nodata wrote:
"PackageKit allows you to install signed content from signed repositories without a password by default. It only asks you to authenticate if anything is unsigned or the signatures are wrong"
If you have a problem with this, do explain why.
a) It contradicts multi user working principles. "Arbitrary console user" is able to kill the application his fellow worker, who is logged in from remote, is working with
b) What if an upgrade fails badly?
c) What if an upgrade requires a reboot.
Not suggesting it is not a problem but being more descriptive does help.
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help.
This opens the door to all kinds of cascaded exploits that would otherwise not be possible (see: http://lwn.net/Articles/362640/). Then local users really get to play root, except that they are really remote users that just broke into your system.
I have no problem with this being a choice an administrator can make, if they feel brave enough to do it. But having this as a default behaviour is just wrong.
-- Bojan
On 11/19/2009 02:30 PM, Bojan Smojver wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help.
This opens the door to all kinds of cascaded exploits that would otherwise not be possible (see: http://lwn.net/Articles/362640/). Then local users really get to play root, except that they are really remote users that just broke into your system.
.. err Jeff Garzik already made that point in this thread.
Rahul
On 11/19/2009 02:49 PM, Bojan Smojver wrote:
On Thu, 2009-11-19 at 14:31 +0530, Rahul Sundaram wrote:
.. err Jeff Garzik already made that point in this thread.
Yeah, so what? Am I not allowed to agree? Or not allowed to point to another site?
IMO, it is not particularly useful in a already long thread to keep repeating the same points.
Rahul
On 11/19/2009 03:51 PM, Bojan Smojver wrote:
On Thu, 2009-11-19 at 15:19 +0530, Rahul Sundaram wrote:
IMO, it is not particularly useful in a already long thread to keep repeating the same points.
Please stop patronising. It's annoying.
Repeating the same thing over and over again is annoying as well. It's just noise instead of useful input.
Rahul
On Thu, 2009-11-19 at 15:49 +0530, Rahul Sundaram wrote:
Repeating the same thing over and over again is annoying as well. It's just noise instead of useful input.
Look, a person expressed an opinion about this screw up on LWN that I find very reasonable. So, I sent my agreement with it to the list, thus indicating that "yes, I agree". And also indicating that another user and small time developer of Fedora is against this idiotic default. Thus trying to convince people in charge that it was a bad idea.
The response was in reply to you because you asked why do people find this behaviour to be a problem. It is a mailing list - you can expect others to reply to your post.
I'm not sure what is not clear about this to you. We don't have +1/-1 system on this list, but at least we can voice our opinion, thus attempting to indicate what the majority of people think about an important issue.
On the other hand, you don't seem to want people talking in bug reports and you don't want them talking on mailing lists.
PS. If you just read my original post and never replied to it, there would have been a lot less spam on the list already. And both of our opinions would have been recorded for everyone to read.
On 11/19/2009 04:22 PM, Bojan Smojver wrote:
On the other hand, you don't seem to want people talking in bug reports and you don't want them talking on mailing lists.
Not true. I just want to avoid repetition and if the points you wanted to make have already been made clearly here and elsewhere, just be patient till the decision is made. In other words, cool off.
Rahul
On Thu, 2009-11-19 at 16:25 +0530, Rahul Sundaram wrote:
Not true. I just want to avoid repetition and if the points you wanted to make have already been made clearly here and elsewhere, just be patient till the decision is made. In other words, cool off.
You really don't get it.
1. Telling people to cool off is patronising, especially when they are not upset.
2. Whether I repeated someone else's point or not is irrelevant. The only relevant thing is that I added my voice.
Now, "till the decision is made" is what I'm trying to get at here. I'm adding my voice so that the _right_ decision (in my opinion) is made.
On Thu, 2009-11-19 at 22:29 +1100, Bojan Smojver wrote:
On Thu, 2009-11-19 at 16:25 +0530, Rahul Sundaram wrote:
Not true. I just want to avoid repetition and if the points you wanted to make have already been made clearly here and elsewhere, just be patient till the decision is made. In other words, cool off.
You really don't get it.
- Telling people to cool off is patronising, especially when they are
not upset.
- Whether I repeated someone else's point or not is irrelevant. The
only relevant thing is that I added my voice.
Now, "till the decision is made" is what I'm trying to get at here. I'm adding my voice so that the _right_ decision (in my opinion) is made.
Look put this simple, if you are not signal you are noise. At this point you are noise, please stop.
Your point was made, you may as well just write +1 as repeat the point, now if you write +1 you realise how dumb this is.
So cool off.
Dave.
On 11/20/2009 02:37 AM, Bojan Smojver wrote:
Dave Airlie <airlied <at> redhat.com> writes:
So cool off.
So, do guys get a course in patronising at RH or do you come up with this stuff all on your own? ;-)
Well done. Good way to indulge in what you accuse other people of.
Nobody's upset. I added my voice. You guys don't like it. Get over it.
Jeff's point was already made by him. An echo serves no purpose.
Rahul
On Fri, 2009-11-20 at 02:41 +0530, Rahul Sundaram wrote:
Well done. Good way to indulge in what you accuse other people of.
Thanks. Did you enjoy it? Joke, joke!
Jeff's point was already made by him.
Yeah, no kidding.
An echo serves no purpose.
200 comments to that bug say otherwise.
On 11/20/2009 02:58 AM, Bojan Smojver wrote:
On Fri, 2009-11-20 at 02:41 +0530, Rahul Sundaram wrote:
An echo serves no purpose.
200 comments to that bug say otherwise.
I would have thought, it should have actually convinced you to not indulge in same thing but apparently not. I will lower my expectations.
Rahul
On Fri, 2009-11-20 at 03:00 +0530, Rahul Sundaram wrote:
I would have thought, it should have actually convinced you to not indulge in same thing but apparently not. I will lower my expectations.
You don't seem to realise that right now you have a protest staged outside your office. Your response appears to be "all you stupid people go home and wait for a decision".
On 11/20/2009 03:55 AM, Bojan Smojver wrote:
On Fri, 2009-11-20 at 03:00 +0530, Rahul Sundaram wrote:
I would have thought, it should have actually convinced you to not indulge in same thing but apparently not. I will lower my expectations.
You don't seem to realise that right now you have a protest staged outside your office. Your response appears to be "all you stupid people go home and wait for a decision".
Nah. I am saying, atleast put up different signs rather than everyone hold up the same signs and make the protest so boring :-)
Rahul
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Nah. I am saying, atleast put up different signs rather than everyone hold up the same signs and make the protest so boring
Lucky it's a virtual protest only. Otherwise, it wouldn't be so boring, now would it, no matter what the signs read? ;-)
-- Bojan
On 11/20/2009 04:11 AM, Bojan Smojver wrote:
Rahul Sundaram writes:
Nah. I am saying, atleast put up different signs rather than everyone hold up the same signs and make the protest so boring
Lucky it's a virtual protest only. Otherwise, it wouldn't be so boring, now would it, no matter what the signs read? ;-)
It still find it boring whether the echo chamber is real or virtual.
Rahul
On Fri, 2009-11-20 at 09:25 +1100, Bojan Smojver wrote:
On Fri, 2009-11-20 at 03:00 +0530, Rahul Sundaram wrote:
I would have thought, it should have actually convinced you to not indulge in same thing but apparently not. I will lower my expectations.
You don't seem to realise that right now you have a protest staged outside your office. Your response appears to be "all you stupid people go home and wait for a decision".
No-one's calling anyone stupid. What would you suggest would be better than escalating the issue at the first available opportunity to the appropriate authority - FESco - which is exactly what's happened? The only alternative is for someone to abuse Red Hat chains of command to force some kind of change in this policy, which is exactly the kind of thing that should _not_ happen in Fedora. The current process appears to precisely the correct one, so far as I can see. The issue will be considered in very timely fashion by the appropriately-constituted (and majority-elected!) authority, which will decide what the appropriate response will be.
Adam Williamson <awilliam <at> redhat.com> writes:
What would you suggest would be better than escalating the issue at the first available opportunity to the appropriate authority - FESco - which is exactly what's happened?
RH folks in charge of this package (or packages) should tell everyone that their concerns have been listened to and that the _default_ will be corrected really soon (e.g. by pointing to a Koji build). It's a bug after all, isn't it?
Now if FESCO want to confirm/revert this fix after hearing all the concerns from people, that's their business.
-- Bojan
On Thu, 2009-11-19 at 23:02 +0000, Bojan Smojver wrote:
Adam Williamson <awilliam <at> redhat.com> writes:
What would you suggest would be better than escalating the issue at the first available opportunity to the appropriate authority - FESco - which is exactly what's happened?
RH folks in charge of this package (or packages) should tell everyone that their concerns have been listened to and that the _default_ will be corrected really soon (e.g. by pointing to a Koji build). It's a bug after all, isn't it?
What has this got to do with Red Hat? you seem to be seriously concerned that people with Red Hat email addresses haven't just fixed this problem.
This is a Fedora issue and its up to the Fedora maintainers (regardless of company) to fix this.
Dave.
Dave Airlie <airlied <at> redhat.com> writes:
What has this got to do with Red Hat? you seem to be seriously concerned that people with Red Hat email addresses haven't just fixed this problem.
It just so happens that people not willing to change this immediately and people telling others to shut up work for RH. I don't think that's my fault.
This is a Fedora issue and its up to the Fedora maintainers (regardless of company) to fix this.
Fine. Would the maintainers of package(s) in question please revert the default, regardless of the company they work for.
-- Bojan
On Thu, Nov 19, 2009 at 02:37:36PM -0800, Adam Williamson wrote:
On Fri, 2009-11-20 at 09:25 +1100, Bojan Smojver wrote:
On Fri, 2009-11-20 at 03:00 +0530, Rahul Sundaram wrote:
I would have thought, it should have actually convinced you to not indulge in same thing but apparently not. I will lower my expectations.
You don't seem to realise that right now you have a protest staged outside your office. Your response appears to be "all you stupid people go home and wait for a decision".
No-one's calling anyone stupid. What would you suggest would be better than escalating the issue at the first available opportunity to the appropriate authority - FESco - which is exactly what's happened? The only alternative is for someone to abuse Red Hat chains of command to force some kind of change in this policy, which is exactly the kind of thing that should _not_ happen in Fedora. The current process appears to precisely the correct one, so far as I can see. The issue will be considered in very timely fashion by the appropriately-constituted (and majority-elected!) authority, which will decide what the appropriate response will be.
Those aren't the only alternatives. There's also the alternative of the maintainers voluntarily making a change to accommodate feedback. A situation where we have one part of the Fedora community giving unwanted marching orders to the other parts of the Fedora community is not an optimal result. (Where that's happened before on rare occasions, it's never been a good thing.)
I'm not saying that FESCo shouldn't have purview over the issue, just that you're really drawing a black and white picture where there's clearly some in-between.
On 11/20/2009 04:37 AM, Paul W. Frields wrote:
Those aren't the only alternatives. There's also the alternative of the maintainers voluntarily making a change to accommodate feedback. A situation where we have one part of the Fedora community giving unwanted marching orders to the other parts of the Fedora community is not an optimal result. (Where that's happened before on rare occasions, it's never been a good thing.)
I'm not saying that FESCo shouldn't have purview over the issue, just that you're really drawing a black and white picture where there's clearly some in-between.
Yes. FESCo is a place to escalate issues when we fail to reach consensus with the maintainers themselves. Everytime, we do this, it is a warning sign that something has gone wrong significantly regardless of the decision being made by FESCo.
Rahul
On Thu, 2009-11-19 at 18:07 -0500, Paul W. Frields wrote:
No-one's calling anyone stupid. What would you suggest would be better than escalating the issue at the first available opportunity to the appropriate authority - FESco - which is exactly what's happened? The only alternative is for someone to abuse Red Hat chains of command to force some kind of change in this policy, which is exactly the kind of thing that should _not_ happen in Fedora. The current process appears to precisely the correct one, so far as I can see. The issue will be considered in very timely fashion by the appropriately-constituted (and majority-elected!) authority, which will decide what the appropriate response will be.
Those aren't the only alternatives. There's also the alternative of the maintainers voluntarily making a change to accommodate feedback. A situation where we have one part of the Fedora community giving unwanted marching orders to the other parts of the Fedora community is not an optimal result. (Where that's happened before on rare occasions, it's never been a good thing.)
I'm not saying that FESCo shouldn't have purview over the issue, just that you're really drawing a black and white picture where there's clearly some in-between.
Sorry, you're quite right, I shouldn't have omitted that bit. I should've explicitly clarified that the above was working from the basis that the maintainer has already said he's not just going to go ahead and change this.
It's also worth noting that there's obviously issues for FESco to discuss here even if the maintainer had decided to go ahead and revert the change, and FESco is the appropriate venue for those wider discussions.
Note to all...
Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to)
I agree with Rahul that it is less productive to "+1" on this email thread.
Jeff
On Nov 19, 2009, at 13:51, Jeff Garzik jgarzik@pobox.com wrote:
Note to all...
Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to)
I agree with Rahul that it is less productive to "+1" on this email thread.
Jeff
Yes because what we really need here is more noise...
Please do /not/ pile on to the bug. It will not help no matter what your opinion is.
-- Jes
On 11/19/2009 07:48 PM, Jesse Keating wrote:
On Nov 19, 2009, at 13:51, Jeff Garzik jgarzik@pobox.com wrote:
Note to all...
Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to)
I agree with Rahul that it is less productive to "+1" on this email thread.
Yes because what we really need here is more noise...
Please do /not/ pile on to the bug. It will not help no matter what your opinion is.
huh?
Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime.
Jeff
On Thu, Nov 19, 2009 at 4:15 PM, Jeff Garzik jgarzik@pobox.com wrote:
Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime.
I'm not aware of a workflow or policy which takes into account bugzilla votes in Fedora. Individual maintainers may or may not consider votes when prioritizing how they use bugzilla, but there's certainly nothing that I am aware that suggests that highly voted on bugs are subject to high level review or discussion as a part of project management. I fear that you are encouraging people to vote with the expectation that the vote will matter in some way when it may not.
-jef
On 11/19/2009 08:25 PM, Jeff Spaleta wrote:
On Thu, Nov 19, 2009 at 4:15 PM, Jeff Garzikjgarzik@pobox.com wrote:
Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime.
I'm not aware of a workflow or policy which takes into account bugzilla votes in Fedora. Individual maintainers may or may not consider votes when prioritizing how they use bugzilla, but there's certainly nothing that I am aware that suggests that highly voted on bugs are subject to high level review or discussion as a part of project management. I fear that you are encouraging people to vote with the expectation that the vote will matter in some way when it may not.
Valid points.
However, I reject the implied notion that ALL feedback from Fedora users must be stifled -- which is the only conclusion one may draw from Fedora leaders asking people to (a) not comment on the list, and (b) not comment on the bug.
I'm curious what Fedora leaders think is the proper forum for __Fedora users__ to register complaints against this policy. Voting seems to be the most efficient, and least spam-y method of doing so, but I am open to suggestions!
Jeff
On Thu, Nov 19, 2009 at 4:34 PM, Jeff Garzik jgarzik@pobox.com wrote:
I'm curious what Fedora leaders think is the proper forum for __Fedora users__ to register complaints against this policy. Voting seems to be the most efficient, and least spam-y method of doing so, but I am open to suggestions!
Voting doesn't mean much if there's no agreement to process the votes. It's inappropriate to run a get out the vote campaign unless there's an agreement that the votes about how they are going to be used for something. Even non-binding public referendums have their place..as long as people are told that they are non-binding and officials are prepared to actually look at the results. We've never had any sort of agreement with regard to how to review bugzilla voting.
But its a good question. The answer of course is putting up an agenda item for discussion with Fesco or the Board depending on the nature of the policy in dispute. I think case Fesco and that's already slated to happen.
But I think you've failed to state something important. I think what you really want to know is how Fedora users can register complaints meant to illicit an immediate response... faster than the turn around one can obtain via a fesco meeting. You want a 911 number to call, instead of a town meeting to speak at. I realize your impatient and I recognize the reasons why, but we don't really think we have a mechanism meant to override a maintainers opinion as fast as you feel it needs to be overturned.
-jef
On 11/19/2009 09:20 PM, Jeff Spaleta wrote:
On Thu, Nov 19, 2009 at 4:34 PM, Jeff Garzikjgarzik@pobox.com wrote:
I'm curious what Fedora leaders think is the proper forum for __Fedora users__ to register complaints against this policy. Voting seems to be the most efficient, and least spam-y method of doing so, but I am open to suggestions!
Voting doesn't mean much if there's no agreement to process the votes.
No, you misunderstand the purpose of Bugzilla voting.
But I think you've failed to state something important. I think what you really want to know is how Fedora users can register complaints meant to illicit an immediate response... faster than the turn around one can obtain via a fesco meeting. You want a 911 number to call, instead of a town meeting to speak at.
No, that's not it at all.
I meant precisely what I said, no more, no less: it makes ZERO sense to squelch Fedora users' feedback. Fedora leaders are saying "no feedback on fedora-devel" and "no feedback on the bugzilla", and now, no Bugzilla voting.
Bugzilla voting was created precisely so that users could raise the profile of a bug and register their voice, without adding actual noise to the discussion. Similar to "like" links on Facebook.
Fedora users -- keep on voting, that is why the feature exists.
Jeff
On Nov 19, 2009, at 17:34, Jeff Garzik jgarzik@pobox.com wrote:
On 11/19/2009 08:25 PM, Jeff Spaleta wrote:
On Thu, Nov 19, 2009 at 4:15 PM, Jeff Garzikjgarzik@pobox.com wrote:
Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime.
I'm not aware of a workflow or policy which takes into account bugzilla votes in Fedora. Individual maintainers may or may not consider votes when prioritizing how they use bugzilla, but there's certainly nothing that I am aware that suggests that highly voted on bugs are subject to high level review or discussion as a part of project management. I fear that you are encouraging people to vote with the expectation that the vote will matter in some way when it may not.
Valid points.
However, I reject the implied notion that ALL feedback from Fedora users must be stifled -- which is the only conclusion one may draw from Fedora leaders asking people to (a) not comment on the list, and (b) not comment on the bug.
I'm curious what Fedora leaders think is the proper forum for __Fedora users__ to register complaints against this policy. Voting seems to be the most efficient, and least spam-y method of doing so, but I am open to suggestions!
We've gotten enough feedback. We don't need 300 more people giving the same arguments over and over or empty +1s or votes. Please relax and let the developer handle it, followed by fesco.
-- Jes
We've gotten enough feedback. We don't need 300 more people giving the same arguments over and over or empty +1s or votes. Please relax and let the developer handle it, followed by fesco.
I'm on Fedora largely for the security policy (best SELinux implementation available, for example), but I can't be the only one seriously considering a switch because of this. Not because the mistake was made, but because I actually watched Fedora developers try to defend it when the only response should have been an immediate fix followed by revocation of all privileges of the package maintainer until his permanent status could be decided.
The total turn around since the initial discovery will be three days come tomorrow's FESCo meeting, plus whatever time it takes after that to get a fix pushed out. That's completely unacceptable. I think an emergency meeting would have been more than appropriate given the situation and general reaction here.
In short: If it hasn't been handled yet, you apparently haven't had nearly enough feedback.
On Thu, 2009-11-19 at 21:57 -0500, Justin wrote:
We've gotten enough feedback. We don't need 300 more people giving the same arguments over and over or empty +1s or votes. Please relax and let the developer handle it, followed by fesco.
I'm on Fedora largely for the security policy (best SELinux implementation available, for example), but I can't be the only one seriously considering a switch because of this. Not because the mistake was made, but because I actually watched Fedora developers try to defend it when the only response should have been an immediate fix followed by revocation of all privileges of the package maintainer until his permanent status could be decided.
The total turn around since the initial discovery will be three days come tomorrow's FESCo meeting, plus whatever time it takes after that to get a fix pushed out. That's completely unacceptable. I think an emergency meeting would have been more than appropriate given the situation and general reaction here.
In short: If it hasn't been handled yet, you apparently haven't had nearly enough feedback.
for folks who are not members of the announce list:
https://www.redhat.com/archives/fedora-announce-list/2009-November/msg00012....
regards, Ankur
On Nov 19, 2009, at 17:15, Jeff Garzik jgarzik@pobox.com wrote:
On 11/19/2009 07:48 PM, Jesse Keating wrote:
On Nov 19, 2009, at 13:51, Jeff Garzik jgarzik@pobox.com wrote:
Note to all...
Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to)
I agree with Rahul that it is less productive to "+1" on this email thread.
Yes because what we really need here is more noise...
Please do /not/ pile on to the bug. It will not help no matter what your opinion is.
huh?
Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime.
I'm familiar. I also know that it isn't goig to accomplish anything in this case.
-- Jes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jesse Keating wrote:
On Nov 19, 2009, at 17:15, Jeff Garzik jgarzik@pobox.com wrote:
On 11/19/2009 07:48 PM, Jesse Keating wrote:
On Nov 19, 2009, at 13:51, Jeff Garzik jgarzik@pobox.com wrote:
Note to all...
Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to)
I agree with Rahul that it is less productive to "+1" on this email thread.
Yes because what we really need here is more noise...
Please do /not/ pile on to the bug. It will not help no matter what your opinion is.
huh?
Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime.
I'm familiar. I also know that it isn't goig to accomplish anything in this case.
It can't hurt anything though, and if it lets people feel as if their voices are being heard, then perhaps there wouldn't be as much traffic on the mailing lists about the issue. The thing is if someone wants to have their voice heard about a given issue, and they have a way of expressing themselves publicly about it somewhere, they're likely to exercise that ability even if other people don't want to hear what they have to say, and when people try to oust them for it or silence them, they're even more likely to express their opinions even louder than before, and bring 1000 minions along with them to make their voices heard louder than before.
The more anyone at all tries to silence anyone else at all in a public forum, for any reason - the more likely the line of conflict between the differing opinions is to cause increasing noise.
Some may say "I don't want to read the noise though", and the answer to that is always "don't, use procmail, or mentally skip over it, hit delete" etc. because the more someone tries to control another person by telling them to go away, the more they are giving their own power away _too_ that other person simply by needing the other person to stop talking in order for them to feel pleasant. It's easier to let people say what they want, and just not read it, and go do something else than to try to control people.
I think the best way to have a loud thread end, is for people who want it to end to just stop reading it or caring about it, and let those who still feel they have something to say express themselves. Once they've done so and have nothing more to say, they'll naturally stop on their own when they're ready.
There are probably 100 billion email and newsgroup threads out there that are tracked by Google which can illustrate this psychological phenomenon. ;o)
It's easy to feel emotional about these types of things, but it really is best to just ignore things we don't want to see and move on.
- -- Mike A. Harris Website: http://mharris.ca Google Wave: mike.andrew.harris - at - googlewave.com https://identi.ca/mharris | https://twitter.com/mikeaharris
On Thu, 19 Nov 2009 18:48:45 -0600, Jesse Keating jkeating@j2solutions.net wrote:
On Nov 19, 2009, at 13:51, Jeff Garzik jgarzik@pobox.com wrote:
Note to all...
Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to)
I agree with Rahul that it is less productive to "+1" on this email thread.
Jeff
Yes because what we really need here is more noise...
Please do /not/ pile on to the bug. It will not help no matter what your opinion is.
-- Jes
So why is everyone replying to it? Think about it.
On Thu, Nov 19, 2009 at 03:49:29PM +0530, Rahul Sundaram wrote:
On 11/19/2009 03:51 PM, Bojan Smojver wrote:
On Thu, 2009-11-19 at 15:19 +0530, Rahul Sundaram wrote:
IMO, it is not particularly useful in a already long thread to keep repeating the same points.
Please stop patronising. It's annoying.
Repeating the same thing over and over again is annoying as well. It's just noise instead of useful input.
Both of you stop, now.
josh (Hall Monitor hairy gorilla)
On Thu, Nov 19, 2009 at 12:19 AM, Bojan Smojver bojan@rexursive.com wrote:
On Thu, 2009-11-19 at 14:31 +0530, Rahul Sundaram wrote:
.. err Jeff Garzik already made that point in this thread.
Yeah, so what? Am I not allowed to agree? Or not allowed to point to another site?
Here are the rules about external reference material. Its only constructive to point to another site if its adding new information from a yet to be heard source that can be reasonably thought of as an authority in the area. Referencing a link to Jeff Garzik's LWN post where he reiterates what he has already said in this mailinglist discussion doesn't add anything. And while Jeff is most certainly free to express the same opinion across multiple concurrent discussions that are happening in multiple places.. its unnecessarily repetitive to cross-reference his comments when he's here already speaking for himself.
-jef
Jeff Spaleta <jspaleta <at> gmail.com> writes:
Referencing a link to Jeff Garzik's LWN post where he reiterates what he has already said in this mailinglist discussion doesn't add anything.
As I already explained, it adds my voice. You may not like that. That's OK with me.
-- Bojan
On Wed, 2009-11-18 at 18:08 +0100, nodata wrote:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Seems fair as the default for a desktop installation.
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
[1]: https://fedoraproject.org/wiki/Features/UserAccountDialog
Am 2009-11-18 18:45, schrieb Bastien Nocera:
On Wed, 2009-11-18 at 18:08 +0100, nodata wrote:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Seems fair as the default for a desktop installation.
It's the opposite behaviour to what is the known behaviour of Linux.
The default should be for the superuser to manage the box, with an option for him or her to allow all users to install software on the box.
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
On Wed, Nov 18, 2009 at 17:45:26 +0000, Bastien Nocera bnocera@redhat.com wrote:
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
This seems pretty reasonable.
On Wed, 2009-11-18 at 12:16 -0600, Bruno Wolff III wrote:
On Wed, Nov 18, 2009 at 17:45:26 +0000, Bastien Nocera bnocera@redhat.com wrote:
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
This seems pretty reasonable.
In the meanwhile the F-11 policy was just fine.
Simo.
Am 2009-11-18 19:16, schrieb Bruno Wolff III:
On Wed, Nov 18, 2009 at 17:45:26 +0000, Bastien Nocerabnocera@redhat.com wrote:
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
This seems pretty reasonable.
I don't like the way Fedora is going with this: digging out something that works and saying "we'll replace it later" makes no sense. Make it work now, or *keep it in*.
On 09-11-18 13:44:43, nodata wrote:
Am 2009-11-18 19:16, schrieb Bruno Wolff III:
On Wed, Nov 18, 2009 at 17:45:26 +0000, Bastien Nocerabnocera@redhat.com wrote:
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
This seems pretty reasonable.
I don't like the way Fedora is going with this: digging out something that works and saying "we'll replace it later" makes no sense. Make it work now, or *keep it in*.
Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called "creative destruction".
Am 2009-11-18 19:50, schrieb Tony Nelson:
On 09-11-18 13:44:43, nodata wrote:
Am 2009-11-18 19:16, schrieb Bruno Wolff III:
On Wed, Nov 18, 2009 at 17:45:26 +0000, Bastien Nocerabnocera@redhat.com wrote:
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
This seems pretty reasonable.
I don't like the way Fedora is going with this: digging out something that works and saying "we'll replace it later" makes no sense. Make it work now, or *keep it in*.
Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called "creative destruction".
and ripping out the boot log for several releases... that was the opposite of helpful.
On 11/18/2009 01:52 PM, nodata wrote:
Am 2009-11-18 19:50, schrieb Tony Nelson:
On 09-11-18 13:44:43, nodata wrote:
Am 2009-11-18 19:16, schrieb Bruno Wolff III:
On Wed, Nov 18, 2009 at 17:45:26 +0000, Bastien Nocerabnocera@redhat.com wrote:
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
This seems pretty reasonable.
I don't like the way Fedora is going with this: digging out something that works and saying "we'll replace it later" makes no sense. Make it work now, or *keep it in*.
Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called "creative destruction".
and ripping out the boot log for several releases... that was the opposite of helpful.
Please do try and stay on topic. This is an entirely unrelated problem which has been resolved.
Am 2009-11-18 21:02, schrieb Peter Jones:
On 11/18/2009 01:52 PM, nodata wrote:
Am 2009-11-18 19:50, schrieb Tony Nelson:
On 09-11-18 13:44:43, nodata wrote:
Am 2009-11-18 19:16, schrieb Bruno Wolff III:
On Wed, Nov 18, 2009 at 17:45:26 +0000, Bastien Nocerabnocera@redhat.com wrote:
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
This seems pretty reasonable.
I don't like the way Fedora is going with this: digging out something that works and saying "we'll replace it later" makes no sense. Make it work now, or *keep it in*.
Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called "creative destruction".
and ripping out the boot log for several releases... that was the opposite of helpful.
Please do try and stay on topic. This is an entirely unrelated problem which has been resolved.
It's related because it's the same problem.
In both cases functionality was missing before a suitable replacement was available.
On 11/18/2009 03:24 PM, nodata wrote:
Am 2009-11-18 21:02, schrieb Peter Jones:
On 11/18/2009 01:52 PM, nodata wrote:
Am 2009-11-18 19:50, schrieb Tony Nelson:
On 09-11-18 13:44:43, nodata wrote:
Am 2009-11-18 19:16, schrieb Bruno Wolff III:
On Wed, Nov 18, 2009 at 17:45:26 +0000, Bastien Nocerabnocera@redhat.com wrote: > > Once we get the new user management stuff into F13 [1], we'd > probably tighten that rule so that only admins are given the > option, or all users but with the need to authenticate as an > admin.
This seems pretty reasonable.
I don't like the way Fedora is going with this: digging out something that works and saying "we'll replace it later" makes no sense. Make it work now, or *keep it in*.
Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called "creative destruction".
and ripping out the boot log for several releases... that was the opposite of helpful.
Please do try and stay on topic. This is an entirely unrelated problem which has been resolved.
It's related because it's the same problem.
In both cases functionality was missing before a suitable replacement was available.
Related to the topic is not the same as on topic.
On Wed, 2009-11-18 at 13:50 -0500, Tony Nelson wrote:
On 09-11-18 13:44:43, nodata wrote:
Am 2009-11-18 19:16, schrieb Bruno Wolff III:
On Wed, Nov 18, 2009 at 17:45:26 +0000, Bastien Nocerabnocera@redhat.com wrote:
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
This seems pretty reasonable.
I don't like the way Fedora is going with this: digging out something that works and saying "we'll replace it later" makes no sense. Make it work now, or *keep it in*.
Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called "creative destruction".
And I'm sure the passive-aggressive in you filed bugs.
On 09-11-18 20:09:18, Bastien Nocera wrote:
On Wed, 2009-11-18 at 13:50 -0500, Tony Nelson wrote:
..
Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called "creative destruction".
And I'm sure the passive-aggressive in you filed bugs.
Yes, I did. Might not have been the passive-aggressive in me, though. Don't be smarmy.
On Thu, 2009-11-19 at 01:48 -0500, Tony Nelson wrote:
On 09-11-18 20:09:18, Bastien Nocera wrote:
On Wed, 2009-11-18 at 13:50 -0500, Tony Nelson wrote:
..
Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called "creative destruction".
And I'm sure the passive-aggressive in you filed bugs.
Yes, I did. Might not have been the passive-aggressive in me, though. Don't be smarmy.
I'm not being smarmy. You just insulted my work, and the work of many other people. I think I'm entitled to an explanation, don't you?
On 09-11-19 05:06:16, Bastien Nocera wrote:
On Thu, 2009-11-19 at 01:48 -0500, Tony Nelson wrote:
On 09-11-18 20:09:18, Bastien Nocera wrote:
On Wed, 2009-11-18 at 13:50 -0500, Tony Nelson wrote:
..
Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called "creative destruction".
And I'm sure the passive-aggressive in you filed bugs.
Yes, I did. Might not have been the passive-aggressive in me, though. Don't be smarmy.
I'm not being smarmy. You just insulted my work, and the work of many other people. I think I'm entitled to an explanation, don't you?
No. If you don't know what Fedora is all about, read the mailing list, even this thread. If you still feel insulted, /grow up/, it's time for you to be a big boy now.
On Wed, 2009-11-18 at 17:45 +0000, Bastien Nocera wrote:
On Wed, 2009-11-18 at 18:08 +0100, nodata wrote:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Seems fair as the default for a desktop installation.
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
And what's wrong with the previous behavior where you were explicitly requested (through a checkbox) whether you liked to give this privilege to users or not ?
Simo.
On 11/18/2009 12:45 PM, Bastien Nocera wrote:
On Wed, 2009-11-18 at 18:08 +0100, nodata wrote:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Seems fair as the default for a desktop installation.
Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin.
No, the sane security answer is to least privileges as-is (require root) until your "new user management stuff" is ready.
Re-read your own post, and realize you proposed:
FC1+: secure F12: insecure F13+ secure again
This is a hugely inconsistent security policy, a special case that administrators must un-learn and re-learn as they go through Fedora versions.
Jeff
Am 2009-11-18 18:08, schrieb nodata:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Just to elaborate:
A local user is allowed to install software on the machine without being prompted for the root password.
This is a recipe for disaster in my opinion.
nodata wrote:
Am 2009-11-18 18:08, schrieb nodata:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Just to elaborate:
A local user is allowed to install software on the machine without being prompted for the root password.
This is a recipe for disaster in my opinion.
So much for granting shell access on my servers. . .
On Wed, 18 Nov 2009, Jon Ciesla wrote:
nodata wrote:
Am 2009-11-18 18:08, schrieb nodata:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Just to elaborate:
A local user is allowed to install software on the machine without being prompted for the root password.
This is a recipe for disaster in my opinion.
So much for granting shell access on my servers. . .
You have PackageKit installed on servers? really?
-sv
Seth Vidal wrote:
On Wed, 18 Nov 2009, Jon Ciesla wrote:
nodata wrote:
Am 2009-11-18 18:08, schrieb nodata:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Just to elaborate:
A local user is allowed to install software on the machine without being prompted for the root password.
This is a recipe for disaster in my opinion.
So much for granting shell access on my servers. . .
You have PackageKit installed on servers? really?
-sv
I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it.
On Wed, 18 Nov 2009, Jon Ciesla wrote:
Seth Vidal wrote:
On Wed, 18 Nov 2009, Jon Ciesla wrote:
nodata wrote:
Am 2009-11-18 18:08, schrieb nodata:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Just to elaborate:
A local user is allowed to install software on the machine without being prompted for the root password.
This is a recipe for disaster in my opinion.
So much for granting shell access on my servers. . .
You have PackageKit installed on servers? really?
-sv
I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it.
Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server.
If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have.
-sv
Am 2009-11-18 19:04, schrieb Seth Vidal:
On Wed, 18 Nov 2009, Jon Ciesla wrote:
Seth Vidal wrote:
On Wed, 18 Nov 2009, Jon Ciesla wrote:
nodata wrote:
Am 2009-11-18 18:08, schrieb nodata:
Yikes! When was it decided that non-root users get to play root?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047
This is horrible!
Just to elaborate:
A local user is allowed to install software on the machine without being prompted for the root password.
This is a recipe for disaster in my opinion.
So much for granting shell access on my servers. . .
You have PackageKit installed on servers? really?
-sv
I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it.
Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server.
If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have.
-sv
Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what.
On Wed, 18 Nov 2009, nodata wrote:
-sv
I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it.
Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server.
If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have.
-sv
Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what.
right - which is why I wouldn't install PK on a server.
yum doesn't allow users to install pkgs, only root.
-sv
Seth Vidal wrote:
On Wed, 18 Nov 2009, nodata wrote:
-sv
I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it.
Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server.
If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have.
-sv
Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what.
right - which is why I wouldn't install PK on a server.
yum doesn't allow users to install pkgs, only root.
-sv
I just found PackageKit on a server that's never been anything but. It was installed fith FC-2, which IIRC is pre-PackageKit. Does this mean it was pulled in by something else that no longer requires it?
On Wed, 18 Nov 2009, Jon Ciesla wrote:
Seth Vidal wrote:
On Wed, 18 Nov 2009, nodata wrote:
-sv
I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it.
Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server.
If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have.
-sv
Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what.
right - which is why I wouldn't install PK on a server.
yum doesn't allow users to install pkgs, only root.
-sv
I just found PackageKit on a server that's never been anything but. It was installed fith FC-2, which IIRC is pre-PackageKit. Does this mean it was pulled in by something else that no longer requires it?
Did you 'yum update' the box from fc-2 to whatever it is now? or how did you get there?
-sv
Seth Vidal wrote:
On Wed, 18 Nov 2009, Jon Ciesla wrote:
Seth Vidal wrote:
On Wed, 18 Nov 2009, nodata wrote:
> -sv > I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it.
Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server.
If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have.
-sv
Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what.
right - which is why I wouldn't install PK on a server.
yum doesn't allow users to install pkgs, only root.
-sv
I just found PackageKit on a server that's never been anything but. It was installed fith FC-2, which IIRC is pre-PackageKit. Does this mean it was pulled in by something else that no longer requires it?
Did you 'yum update' the box from fc-2 to whatever it is now? or how did you get there?
-sv
Yes, precisely, one release at a time. Plan to do 12 in a few days.
On Wed, 2009-11-18 at 13:10 -0500, Seth Vidal wrote:
Maybe you have a different concept of security, but I don't want any
user on
the server installing software, no matter what.
right - which is why I wouldn't install PK on a server.
yum doesn't allow users to install pkgs, only root.
Seth, the fact you prefer to use yum doesn't make it right to have an insecure-by-default policy.
Simo.
On Wed, 18 Nov 2009, Simo Sorce wrote:
On Wed, 2009-11-18 at 13:10 -0500, Seth Vidal wrote:
Maybe you have a different concept of security, but I don't want any
user on
the server installing software, no matter what.
right - which is why I wouldn't install PK on a server.
yum doesn't allow users to install pkgs, only root.
Seth, the fact you prefer to use yum doesn't make it right to have an insecure-by-default policy.
I didn't say it did - I said it didn't make sense to have items like PK on servers.
-sv
Am 2009-11-18 19:28, schrieb Seth Vidal:
On Wed, 18 Nov 2009, Simo Sorce wrote:
On Wed, 2009-11-18 at 13:10 -0500, Seth Vidal wrote:
Maybe you have a different concept of security, but I don't want any
user on
the server installing software, no matter what.
right - which is why I wouldn't install PK on a server.
yum doesn't allow users to install pkgs, only root.
Seth, the fact you prefer to use yum doesn't make it right to have an insecure-by-default policy.
I didn't say it did - I said it didn't make sense to have items like PK on servers.
It doesn't make sense to define the security setup of a machine based on "oh well packagekit is installed, so it must be a desktop machine for which there is one or maybe two primary users who are all trusted to decide if they want to install software".
The fact is that there is quite a lot of badly written software that requires X to install. In fact, Red Hat's documentation tends to assume that X is installed by default. So do Red Hat's courses. And even their toolset. Ever used system-config-lvm-tui? No, it doesn't exist.
If X is there, PackageKit is there. The claimed link between the intended use and security profile of a machine depending on whether PackageKit is installed makes no sense.
It doesn't matter if I or you prefer @core on our servers, the customers want X because they're new to Linux and feel comfortable with it. They won't have some arcane knowledge about the disconnect between yum and rpm with packagekit, and how sometimes you have to be root, sometimes you don't.
Secure by default please, otherwise turn off selinux by default.
nodata wrote:
It doesn't make sense to define the security setup of a machine based on "oh well packagekit is installed, so it must be a desktop machine for which there is one or maybe two primary users who are all trusted to decide if they want to install software".
And the irony in all this is that this "the security requirements of the machine are defined by what packages are, or rather are not, installed" assumption is exactly what makes this very "feature" such a security risk!
Kevin Kofler
Verily I say unto thee, that nodata spake thusly:
Secure by default please, otherwise turn off selinux by default.
Very good point.
It's rather contradictory, indeed hypocritical, for Fedora to have spent all this time and effort integrating security as relatively extreme as SELinux into the distro, only to then undermine it by allowing a subset of unauthorised root privileges.
So on the one hand the rationale is: The target audience is single-user desktops, so authorising package installs is moot. But on the other hand those same users had to endure several releases where SELinux prevented many packages from working correctly, while maintainers, developers, and bug reporters spent a lot of time and effort tweaking security policies to fix these issues, for the sake of what was extolled as important and necessary improvements to Linux security.
So which is it?
Is security important for the target audience (whomever Fedora presumes them to be), or not?
Personally, I use Fedora on desktops, laptops /and/ servers, and yes I have other users on my network, to whom I do /not/ wish to allow root access ... ever. And I take great exception to Fedora arrogantly presuming what type of systems I use Fedora on, and what my security needs are.
Something far more worrying, is that Fedora is the testbed for RHEL. Are we to assume that enterprise customers will be spared the insecurities currently being foisted on Fedora users, or should we start working on the security advisories now?
On Wed, 2009-11-18 at 13:28 -0500, Seth Vidal wrote:
On Wed, 18 Nov 2009, Simo Sorce wrote:
On Wed, 2009-11-18 at 13:10 -0500, Seth Vidal wrote:
Maybe you have a different concept of security, but I don't want any
user on
the server installing software, no matter what.
right - which is why I wouldn't install PK on a server.
yum doesn't allow users to install pkgs, only root.
Seth, the fact you prefer to use yum doesn't make it right to have an insecure-by-default policy.
I didn't say it did - I said it didn't make sense to have items like PK on servers.
add "for me" and I can agree with you.
Note I also don't like to install "desktop grade" packages on servers, but that's just a preference, and should in no way change the security of the machine.
Conscious choices: +1 Insecure defaults: -1 Difficult to find out how to change insecure defaults: -10
Simo.
On 11/18/2009 01:28 PM, Seth Vidal wrote:
I didn't say it did - I said it didn't make sense to have items like PK on servers.
Listen to yourself.
The above is a blatant admission that it is REALLY EASY for existing users to upgrade themselves into a security nightmare.
* F11 w/ PK: requires root * F12 w/ PK: does not require root
And you don't see any problem with this?
Jeff
On Wed, 18 Nov 2009, Jeff Garzik wrote:
On 11/18/2009 01:28 PM, Seth Vidal wrote:
I didn't say it did - I said it didn't make sense to have items like PK on servers.
Listen to yourself.
The above is a blatant admission that it is REALLY EASY for existing users to upgrade themselves into a security nightmare.
- F11 w/ PK: requires root
- F12 w/ PK: does not require root
And you don't see any problem with this?
you're talking to the wrong guy.
I don't maintain PK. I don't work on PK. I don't have anything to do with it, in fact.
And you should listen to yourself. I'm saying: You want to run secure servers, then you have to know what's on the system. Not just what pkg, but what the pkg does.
This is why I said: It doesn't make sense to have programs like packagekit which are targeted at end users on servers.
-sv
On Wed, 18 Nov 2009, Jeff Garzik wrote:
On 11/18/2009 01:28 PM, Seth Vidal wrote:
I didn't say it did - I said it didn't make sense to have items like PK on servers.
Listen to yourself.
The above is a blatant admission that it is REALLY EASY for existing users to upgrade themselves into a security nightmare.
- F11 w/ PK: requires root
- F12 w/ PK: does not require root
And you don't see any problem with this?
I can invent problems with this if I want to. But I suspect that when F13 comes out, people will look back on F12 and find PK more usable not less secure even though it is technically both.
-Mike
Seth Vidal wrote:
On Wed, 18 Nov 2009, nodata wrote:
-sv
I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it.
Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server.
If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have.
Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what.
right - which is why I wouldn't install PK on a server.
yum doesn't allow users to install pkgs, only root.
$ sudo rpm -e PackageKit error: Failed dependencies: ... PackageKit is needed by (installed) setroubleshoot-2.2.42-1.fc12.x86_64
Ouch. I like setroubleshoot.
Is there some way to disable PackageKit but keep setroubleshoot?
Andrew.
2009/11/18 Andrew Haley aph@redhat.com:
Is there some way to disable PackageKit but keep setroubleshoot?
Just set all the policykit answers to "no". You'll find more than just setroubleshoot breaks if you do this.
Richard.
On Wed, 18 Nov 2009, Richard Hughes wrote:
2009/11/18 Andrew Haley aph@redhat.com:
Is there some way to disable PackageKit but keep setroubleshoot?
Just set all the policykit answers to "no". You'll find more than just setroubleshoot breaks if you do this.
How do you do this? Set the policykit answers to no?
-sv
On Wed, 2009-11-18 at 14:29 -0500, Seth Vidal wrote:
On Wed, 18 Nov 2009, Richard Hughes wrote:
2009/11/18 Andrew Haley aph@redhat.com:
Is there some way to disable PackageKit but keep setroubleshoot?
Just set all the policykit answers to "no". You'll find more than just setroubleshoot breaks if you do this.
How do you do this? Set the policykit answers to no?
The atom-bomb approach is to change everything in /usr/share/polkit-1/actions/ to <allow_active>no</allow_active> and <allow_inactive>no</allow_inactive>.
But that's not right because those files aren't config files. Instead, you drop "local authority" files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are.
Dan
On Wed, Nov 18, 2009 at 10:45 AM, Dan Williams dcbw@redhat.com wrote:
But that's not right because those files aren't config files. Instead, you drop "local authority" files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are.
Beyond the issue of what is and what is not the appropriate default at install time..which is already a difficult issue to talk through. I think there is an education gap here about how to competently admin PolicyKit based activities which adds frustration.
-jef"old dogs...new tricks"spaleta
On Wed, 2009-11-18 at 10:53 -0900, Jeff Spaleta wrote:
On Wed, Nov 18, 2009 at 10:45 AM, Dan Williams dcbw@redhat.com wrote:
But that's not right because those files aren't config files. Instead, you drop "local authority" files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are.
Beyond the issue of what is and what is not the appropriate default at install time..which is already a difficult issue to talk through. I think there is an education gap here about how to competently admin PolicyKit based activities which adds frustration.
-jef"old dogs...new tricks"spaleta
That often happens with new software. The trikiest part is finding the proper documentation. man 8 polkit seems like a very good starting point.
Jeff Spaleta wrote:
Beyond the issue of what is and what is not the appropriate default at install time..which is already a difficult issue to talk through. I think there is an education gap here about how to competently admin PolicyKit based activities which adds frustration.
Another big issue is that polkit-gnome-authorization and polkit-kde- authorization were not ported to / rewritten for PolicyKit 1, I've been told a polkit-gnome-authorization port/rewrite is not even planned anymore (despite having originally been a requirement for PolicyKit 1 and despite this being a major feature regression compared to 0.9), and the polkit-kde- authorization port/rewrite is planned, but not even started (the people working on it are still busy with making the rest of PolicyKit 1 KDE integration happen).
The absence of a GUI policy editor combined with lack of documentation for the config files makes bad defaults a big issue.
Kevin Kofler
Kevin Kofler wrote:
The absence of a GUI policy editor combined with lack of documentation for the config files makes bad defaults a big issue.
This is a key issue. Do I take it that I have to edit the XML files directly to require authentication for package installs?
So far I have:
$ pkaction -v --action-id org.freedesktop.packagekit.package-install org.freedesktop.packagekit.package-install: description: Install signed package message: Authentication is required to install a signed package vendor: The PackageKit Project vendor_url: http://www.packagekit.org/ icon: package-x-generic implicit any: no implicit inactive: no implicit active: yes
I'm not sure what to change here. I'm guessing that I should change "implicit active: yes" to "implicit active: auth_admin". And that I should do this in /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy
Andrew.
On 11/19/2009 04:51 PM, Andrew Haley wrote:
I'm not sure what to change here. I'm guessing that I should change "implicit active: yes" to "implicit active: auth_admin". And that I should do this in /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy
Follow
http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Note...
More details at
http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-...
Rahul
Once upon a time, Dan Williams dcbw@redhat.com said:
But that's not right because those files aren't config files. Instead, you drop "local authority" files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are.
Um, what is /var/lib/polkit-1/localauthority/? Again, I'm still sitting at my F11 desktop; was this something added in F12?
Maybe (as someone else mentioned) I am looking for the 1000 foot (or 305 meter) view. I understand setuid-root, setgid-foo, etc., and that is widely documented. I kind of have a grip on consolehelper, more from poking around at it than reading anything. I have no clue how things work with PolicyKit, and it also seems that PolicyKit is still changing how things are done from release to release.
I poked at PolicyKit a little when someone pointed out desktop users were allowed to change the system clock a couple of releases ago. Some of the same discussion happened then as is happening now; I made the same suggestion about "no elevated access by default and spins can override". The clock perms finally changed in F12 (although it looks like users can still change the timezone, which is still not a good idea, as most things like cron and syslog use local time), and now we have PackageKit questions.
It just seems like there needs to be:
- better documentation - better defaults - better Fedora policy - better oversight (or enforcement, if necessary)
about PolicyKit (or anything that can give regular users elevated access) rules and actions.
On Wed, 18 Nov 2009, Dan Williams wrote:
On Wed, 2009-11-18 at 14:29 -0500, Seth Vidal wrote:
On Wed, 18 Nov 2009, Richard Hughes wrote:
2009/11/18 Andrew Haley aph@redhat.com:
Is there some way to disable PackageKit but keep setroubleshoot?
Just set all the policykit answers to "no". You'll find more than just setroubleshoot breaks if you do this.
How do you do this? Set the policykit answers to no?
The atom-bomb approach is to change everything in /usr/share/polkit-1/actions/ to <allow_active>no</allow_active> and <allow_inactive>no</allow_inactive>.
But that's not right because those files aren't config files. Instead, you drop "local authority" files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are.
To be fair - it took 2 engineers about 30-40 minutes and looking through the code to figure out what was wanted in those files and then how to verify what was in there.
it resulted in: http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-...
but the manpages do not make it obvious. nor is it obvious why those files are in /var/lib/
-sv
On Wed, Nov 18, 2009 at 11:45:14AM -0800, Dan Williams wrote:
But that's not right because those files aren't config files. Instead, you drop "local authority" files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are.
The config files live in /var?
Really.