On Thu, Nov 19, 2009 at 12:40 PM, Jesse Keating <jkeating@xxxxxxxxxx> wrote: > On Thu, 2009-11-19 at 12:33 -0500, Gregory Maxwell wrote: >> ...add what you want, and have PolicyKit pulled in as a dependency. >> When this discussion came up I tried doing a yum erase PolicyKit on >> one of my systems and had it offer to remove some 372 package, >> including xorg-x11-drivers. > I'm not sure what you're trying to say here. PolicyKit is an integral > part of our distribution. The policies that get loaded into PolicyKit > can come from different sources though, either a blanket policy package, > or individual policy files to go along with individual packages. So in > your case, while you have PolicyKit installed, you may not have had > PackageKit, nor the policy that would grant PackageKit to do thing for > local users. We obviously must be talking past each other. I see people complaining that they don't want these non-unixy policies being silently installed on systems where they are surprising and where they are configured in invisible ways that skilled unix admins will fail to discover. You pointed out that a server install can/should be conducted by installing a fairly limited set of packages. I'm trying to point out that installing limited packages doesn't fix the problem because it is not clear which packages are responsible for setting (subverting, depending on your outlook) system wide security policy… except PolicyKit itself, which you can't leave out. In the past I could simply check to see if a package contained SUID 0 binaries or modified a small number of fairly obvious system config files and have good confidence that it wasn't changing the root/user boundary line. This takes us back to the beginning of the thread where Chris was calling for auditing, oversight, and accounting for significant security modifying behaviours. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
