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.
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?
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 Edge - LWN - jake(a)lwn.net - http://lwn.net
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:
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.
-----BEGIN PGP SIGNED MESSAGE-----
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
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
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
-----END PGP SIGNATURE-----