security November 2008

security@lists.fedoraproject.org

8 participants
4 discussions

Security reviews for new packages
by Jason L Tibbitts III 14 Jan '09

14 Jan '09

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<

3 4

fedora 10 updates
by Jake Edge 24 Nov '08

24 Nov '08

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(a)lwn.net - http://lwn.net

2 1

CVE-2008-5138 pam_mount insecure tempfile creation - to update or not?
by Till Maas 23 Nov '08

23 Nov '08

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

2 1

PolicyKit Proliferation is a Security Disaster in the making.
by Daniel J Walsh 10 Nov '08

10 Nov '08

-----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-----

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security November 2008