Security policy oversight needed?

[nodata]

Am 2009-11-19 00:58, schrieb Chris Adams:
> After seeing two conflicts over PolicyKit default policies allowing
> unprivileged to do things that previously only root could do, it seems
> to me that there needs to be some kind of oversight on security policy
> for the distribution.  Right now, any package maintainer can make
> changes to system security policy, without announcing it, getting any
> approval, etc.
>
> In the two cases I've seen, the maintainers decided that their way was
> the right way and closed the bug reports without any real discussion,
> which just seems unacceptable to me.
>
> Any package (whether new or an update) that adds/changes PolicyKit,
> consolehelper, or PAM configuration, and anything that installs new
> setuid/setgid executables, should require some additional third-party
> review.  Any significant changes that passes review should require some
> minimum amount of advance notice and documentation on how to revert
> (preferably in some common easy-to-find place in the wiki).
>
> Is this feasible?  Who needs to look at this?
>
> I would like to see this discussion separate from discussion about the
> current issue with PackageKit.
>

I would like to see (and I brought this up on the list before) a page 
listing selinux exceptions. That is: applications which are essentially 
untrusted because of weird things they do with memory or whatever. The 
list would be in two parts: apps that have to be like this because of 
how they work (e.g. Java, mono) and apps that are badly written and 
should be fixed (firefox was/is one culprit).

The list would ensure two things:
1. That there is visibility of what selinux does not cover
2. That bad applications get attention or at least exposure