From dwalsh at redhat.com Thu Nov 6 17:04:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 06 Nov 2008 12:04:45 -0500 Subject: PolicyKit Proliferation is a Security Disaster in the making. Message-ID: <491323AD.70509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Currently I am aware of at least 4 "PolicyKit" apps in Fedora 10 with a lot more on the way. I believe we are not treating these as the security vulnerability that they represent. Now I do NOT believe there is anything wrong with PolicyKit itself. The problems is in the apps that are using it. Lets take a look at system-config-services. This service comes up and prompts me for the root password before I start and stop a service. That is good, works just like it did when system-config-services used consolehelper. Except for one problem, it defaults to a clicked "Remember authorization" meaning the next time I run system-config-services it will NOT prompt for the password. Now there is a check box for "This session only" But it is defaulted to off also. So this means that I clicked "Start A service" Entered the "Root Password" and took the default. Now any process on my desktop has the ability to start and stop any service on my machine without me even knowing about it???? There also might be a bug in system-config-services communications with dbus that would allow me to spawn a root shell. This is the equivalent or worse then a setuid app, and yet we do nothing to control the proliferation of these apps, while we shut down all apps that setuid!!!! All PolicyKit app that requires the Admin Password should default to "For this Session Only", and potentially for this action only. Consolekit only preserved the authentication for 5 minutes, by default, now we preserve it for ever by default. The argurment can be made that consolehelper used to be allowed to permanently save the user being allowed, but this involved an admin editing a file and probably a better understanding of what he is doing. SELinux can help a little to mitigate the risk but SELinux is not going to be running everywhere. And for something like system-config-services, SELinux can do almost nothing since the tool needs to start and stop all services which is a pretty high level of security. Fedora Security team should be looking at all packages that get PolicyKit integration to make sure they are secure, have the correct PolicyKit authorization, and a security check should be put on the service side of the app. I think we should write lint apps to look at PolicyKit specifications and look for vulnerable xml policy. Rpmlint and RPMDiff should run this to make sure apps are secure by default. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkTI6wACgkQrlYvE4MpobM/cgCdHDl8UwPJEfgi0Kg0bJ4U4zKS KpEAoJUrIvU2fFCSazlTwYPTKuLx5YjT =HLnc -----END PGP SIGNATURE----- From eric.rannaud at gmail.com Thu Nov 6 22:03:22 2008 From: eric.rannaud at gmail.com (Eric Rannaud) Date: Thu, 06 Nov 2008 14:03:22 -0800 Subject: PolicyKit Proliferation is a Security Disaster in the making. In-Reply-To: <491323AD.70509@redhat.com> References: <491323AD.70509@redhat.com> Message-ID: <1226009002.21653.19.camel@nc050> On Thu, 2008-11-06 at 12:04 -0500, Daniel J Walsh wrote: > Lets take a look at system-config-services. This service comes up and > prompts me for the root password before I start and stop a service. That > is good, works just like it did when system-config-services used > consolehelper. Incidentally, a related problem with this is that as a user I have no way of knowing which application generated that pop-up dialog asking for my root password. I may be wrong, but I don't believe there is any way whatsoever for the user to tell reliably that the pop-up dialog is legitimate. If there is a way to tell it is legitimate, it is not quite obvious enough. The only clue I can have that I should indeed input my password is timing. If I didn't do anything mandating a request for my root password in the previous second, I'm unlikely to trust the pop-up. But this is obviously a very weak security guarantee. As an example scenario, I believe any user application can be notified when the network connection goes up and down (through D-Bus?). Such a connection related event is probably a good time for a rogue application to display such a pop-up. (e.g. with the tendency of wireless connection to go down unexpectedly at random times). This is not a very smart scenario, I'm sure attackers would come up with much more convincing ones, but that one would work at least on some users some of the time. Any arbitrary code execution vulnerability in a user space application like Firefox has the potential of becoming a successful remote root exploit, just because the user got fooled. This weakness has been present for quite a while now, I would imagine people have thought about it before. But it may be worth thinking about it again, especially in light of the recent trend to ask for you root password in new and unexpected way at odd times. Regards, Eric. From kevin at tummy.com Mon Nov 10 23:03:43 2008 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 10 Nov 2008 16:03:43 -0700 Subject: PolicyKit Proliferation is a Security Disaster in the making. In-Reply-To: <491323AD.70509@redhat.com> References: <491323AD.70509@redhat.com> Message-ID: <20081110160343.0f6f4d7f@ohm.scrye.com> On Thu, 06 Nov 2008 12:04:45 -0500 Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Currently I am aware of at least 4 "PolicyKit" apps in Fedora 10 with > a lot more on the way. I believe we are not treating these as the > security vulnerability that they represent. Now I do NOT believe > there is anything wrong with PolicyKit itself. The problems is in > the apps that are using it. I see 19 packages that drop files in the policykit dir... argyllcms-0:1.0.3-1.fc10.x86_64 ConsoleKit-0:0.3.0-2.fc10.x86_64 control-center-1:2.24.0.1-9.fc10.x86_64 DeviceKit-disks-0:002-0.git20080720.fc10.x86_64 DeviceKit-power-0:001-2.fc10.x86_64 GConf2-0:2.24.0-1.fc10.x86_64 gnome-applets-1:2.24.1-1.fc10.x86_64 gnome-lirc-properties-0:0.3.1-1.fc10.noarch gnome-panel-0:2.24.1-3.fc10.x86_64 gnome-system-monitor-0:2.24.1-1.fc10.x86_64 hal-0:0.5.12-12.20081027git.fc10.x86_64 libvirt-0:0.4.6-3.fc10.x86_64 NetworkManager-1:0.7.0-0.11.svn4229.fc10.x86_64 PackageKit-0:0.3.9-4.fc10.x86_64 pulseaudio-0:0.9.13-6.fc10.x86_64 system-config-samba-0:1.2.66-1.fc10.noarch system-config-services-0:0.99.25-1.fc10.noarch thinkfinger-0:0.3-8.fc9.x86_64 > Lets take a look at system-config-services. This service comes up and > prompts me for the root password before I start and stop a service. > That is good, works just like it did when system-config-services used > consolehelper. Except for one problem, it defaults to a clicked > "Remember authorization" meaning the next time I run > system-config-services it will NOT prompt for the password. Now there > is a check box for "This session only" But it is defaulted to off > also. Is that default in the app config? Or in PolicyKit itself? Ah, looks like the app, so thats bad. :( > So this means that I clicked "Start A service" Entered the "Root > Password" and took the default. Now any process on my desktop has the > ability to start and stop any service on my machine without me even > knowing about it???? There also might be a bug in > system-config-services communications with dbus that would allow me to > spawn a root shell. > > This is the equivalent or worse then a setuid app, and yet we do > nothing to control the proliferation of these apps, while we shut > down all apps that setuid!!!! > > All PolicyKit app that requires the Admin Password should default to > "For this Session Only", and potentially for this action only. > Consolekit only preserved the authentication for 5 minutes, by > default, now we preserve it for ever by default. The argurment can > be made that consolehelper used to be allowed to permanently save the > user being allowed, but this involved an admin editing a file and > probably a better understanding of what he is doing. Perhaps a few minutes and something like when the screensaver starts it automatically removes all current auths? > SELinux can help a little to mitigate the risk but SELinux is not > going to be running everywhere. And for something like > system-config-services, SELinux can do almost nothing since the tool > needs to start and stop all services which is a pretty high level of > security. > > Fedora Security team should be looking at all packages that get > PolicyKit integration to make sure they are secure, have the correct > PolicyKit authorization, and a security check should be put on the > service side of the app. I think we should write lint apps to look > at PolicyKit specifications and look for vulnerable xml policy. > Rpmlint and RPMDiff should run this to make sure apps are secure by > default. Yeah, I agree. I was going to suggest that this discussion should take place on an upstream PolicyKit list, but I can't seem to find one anywhere. ;( kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tibbs at math.uh.edu Tue Nov 11 15:51:23 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Nov 2008 09:51:23 -0600 Subject: Security reviews for new packages Message-ID: I do many package reviews, and occasionally I see a package that is fine packaging-wise but which I don't feel comfortable approving because I know it has security implications. One such package is schroot, which has some pam magic to allow users to set up chroots. https://bugzilla.redhat.com/show_bug.cgi?id=447368 It's quite possible that I'm simply being overly paranoid, but of course I'm not qualified to say one way or the other. Is it possible for someone with more knowledge in this area to take a look at the package? What would be needed? (Perhaps a scratch build, or are the src.rpm and spec sufficient?) Could we work out a simple procedure for doing this in the future? - J< From kevin at tummy.com Tue Nov 11 18:21:12 2008 From: kevin at tummy.com (Kevin Fenzi) Date: Tue, 11 Nov 2008 11:21:12 -0700 Subject: Security reviews for new packages In-Reply-To: References: Message-ID: <20081111112112.463f7411@ohm.scrye.com> On 11 Nov 2008 09:51:23 -0600 Jason L Tibbitts III wrote: > I do many package reviews, and occasionally I see a package that is > fine packaging-wise but which I don't feel comfortable approving > because I know it has security implications. One such package is > schroot, which has some pam magic to allow users to set up chroots. > https://bugzilla.redhat.com/show_bug.cgi?id=447368 > > It's quite possible that I'm simply being overly paranoid, but of > course I'm not qualified to say one way or the other. Is it possible > for someone with more knowledge in this area to take a look at the > package? What would be needed? (Perhaps a scratch build, or are the > src.rpm and spec sufficient?) I'm no expert, but I could take a look I suppose. > Could we work out a simple procedure for doing this in the future? How about we make a F_SECURITY_REVIEW tracker bug, and any review that needs extra security attention is made to block that bug. We can add this list to that blocker to notify everyone here to take a look? (It's worked for LEGAL I think, so I would hope it works for security reviews as well). Thoughts? > - J< kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tibbs at math.uh.edu Tue Nov 11 19:31:00 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Nov 2008 13:31:00 -0600 Subject: Security reviews for new packages In-Reply-To: <20081111112112.463f7411@ohm.scrye.com> References: <20081111112112.463f7411@ohm.scrye.com> Message-ID: >>>>> "KF" == Kevin Fenzi writes: KF> I'm no expert, but I could take a look I suppose. Another pair of eyes won't hurt, of course, but honestly I don't know what's involved in an actual secuity review. KF> How about we make a F_SECURITY_REVIEW tracker bug, and any review KF> that needs extra security attention is made to block that bug. Well, that would work but I'm thinking it's a bit premature to talk about it until we know that there's at least one proper trained security person who will actually pay attention to it. I just don't want to have the security team's first contact with a package like this to be the posting of CVEs. - J< From opensource at till.name Fri Nov 21 21:51:32 2008 From: opensource at till.name (Till Maas) Date: Fri, 21 Nov 2008 22:51:32 +0100 Subject: CVE-2008-5138 pam_mount insecure tempfile creation - to update or not? Message-ID: <200811212251.32939.opensource@till.name> Hiyas, there was a bug report opened because of an possible vulnerability in pam_mount, which I would not really consider one. Because it cannot be triggered under normal circumstances because the script would fail before an insecure tempfile is used. More details are available here: https://bugzilla.redhat.com/show_bug.cgi?id=472109#c2 The question is now, whether I should update the package without the affected script to make everyone aware of this or just keep it as is. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From thoger at redhat.com Sun Nov 23 20:42:35 2008 From: thoger at redhat.com (Tomas Hoger) Date: Sun, 23 Nov 2008 21:42:35 +0100 Subject: CVE-2008-5138 pam_mount insecure tempfile creation - to update or not? In-Reply-To: <200811212251.32939.opensource@till.name> References: <200811212251.32939.opensource@till.name> Message-ID: <20081123214235.4d7514f7@redhat.com> Hi Till! Comment added to BZ as well... On Fri, 21 Nov 2008 22:51:32 +0100 Till Maas wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=472109#c2 > > The question is now, whether I should update the package without the > affected script to make everyone aware of this or just keep it as is. This has a very low impact due to the reasons you have explained. For Red Hat Enterprise Linux we tend to postpone fixing low impact issues, it should be fine to deal with this once there's a better reason to do new packages. -- Tomas Hoger / Red Hat Security Response Team From jake at lwn.net Mon Nov 24 17:51:16 2008 From: jake at lwn.net (Jake Edge) Date: Mon, 24 Nov 2008 10:51:16 -0700 Subject: fedora 10 updates Message-ID: <20081124105116.08d5aec5@chukar> there appear to be half-a-dozen or so Fedora 10 updates (from over the weekend) all of which have the FEDORA-2008-10000 identifier ... a quick google suggests there are F9 updates in the pipeline with that identifier as well ... some kind of year 10K problem? jake -- Jake Edge - LWN - jake at lwn.net - http://lwn.net From dennis at ausil.us Mon Nov 24 18:43:53 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 24 Nov 2008 12:43:53 -0600 Subject: fedora 10 updates In-Reply-To: <20081124105116.08d5aec5@chukar> References: <20081124105116.08d5aec5@chukar> Message-ID: <200811241243.54128.dennis@ausil.us> On Monday 24 November 2008 11:51:16 am Jake Edge wrote: > there appear to be half-a-dozen or so Fedora 10 updates (from over the > weekend) all of which have the FEDORA-2008-10000 identifier ... a quick > google suggests there are F9 updates in the pipeline with that > identifier as well ... some kind of year 10K problem? > > jake its a bug in bodhi. it was discovered last week. it was mentioned on fedora- infrastructure-list https://www.redhat.com/archives/fedora-infrastructure- list/2008-November/msg00150.html just waiting for the patch to be deployed and errata's to be regenerated Dennis