Security policy oversight needed?

[Gregory Maxwell]

On Thu, Nov 19, 2009 at 12:40 PM, Jesse Keating <jkeating at redhat.com> 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.