Security policy oversight needed?

[Peter Jones]

On 11/18/2009 08:11 PM, Chris Adams wrote:
> Once upon a time, Mike McGrath <mmcgrath at redhat.com> said:
>> I think that's too subjective though.
> 
> What is subjective about "allowing unprivileged to do things that
> previously only root could do"?
> 
>> I'd be more in favor of a simple,
>> broad view of what the user should be able to do without root.  It's
>> possible "install packages" would be on that list, it's possible not.
>> That way packages could ask themselves "does this break the policy?"  If
>> it doesn't, great.  If it does, time for a bug report.
> 
> There have been bug reports, but they get closed by the maintainers as
> NOTABUG, so that procedure is obviously not working.

This conclusion doesn't make a whole lot of sense.  There's no guideline in
place, so package maintainers aren't given the guidance Mike's suggesting.
Without that guidance, closed->NOTABUG is not an indication of whether this
process works, because there's no process being followed.

To be perfectly frank, "any packager has the power to change behavior" is
exactly how it should be. Right now developers using PK are basically deciding
policy on their own, with no guidance as to the grander plan, and people are
evaluating the quality of these decisions without a real, tangible reference
point.  There does need to be a way for a developer or packager to know if or
how they /should/ be changing security-relevant behaviors, and for others to
evaluate if the change is good or bad.  

Mike's suggestion of a distro-wide policy is one way to do that, and on it's
face, it's certainly a lot more practical than a distro wide change control
board auditing for security relevant changes, or even sillier, expecting
package maintainers to identify when a change has security implications and
come asking what they should do.  A "command" infrastructure does not fit
Fedora or Linux very well.

I think the policy should be in two parts, though.  Mike's suggestion is good;
we need general guidelines as to what roles which classes of users are expected
to fulfill.  We probably also need some packaging policy for applications
providing escalated privileges via policy kit, like we already have for setuid
utilities.

-- 
        Peter

If you're not part of the solution, then you're part of the precipitate.