Extras Security Policy

[Warren Togami]

Hans de Goede wrote:
> 
> Besides that we need a clear security policy to be written and approved
> by fesco:
SNIP
> 
> We really need an FE security team which wathces over FE's security 
> aspects.

Generally everyone agrees about "need" ...

> 
> I'm in no way volunteering todo any of the work this will cause, not 
> because I don't want to, but because I don't have the time.
> 

but security is *hard* for volunteers to do.  Nobody is accountable 
because it isn't their job responsibility.  Volunteers generally do the 
"fun" things first, and sometimes one-time harder problems.  This does 
not describe what it takes to maintain eternal vigilance necessary of 
people focused on security in the long-term.  I am talking here of 
realistic expectations of volunteer capability.

http://lwn.net/Articles/149976/
The referenced LWN security article writer was surprised by Debian's 
slowest response time to security issues, and while they were impressed 
by Fedora and other company supported distribution support times, they 
were concerned about community maintained distros like Extras.  This is 
indicative of the ability of volunteer groups to adequately deal with 
security.

(The example that they used of Clamav however was strange, in that 
Extras actually did do a decent job of quickly upgrading to 0.86.2 after 
the advisory was released.)

It is problematic to say "We really need an FE security team" but also 
say, "I'm in no way volunteering todo any of the work".  This too is 
indicative of realistic capabilities and expectations of volunteers.

There are things that we can do like improve the package review 
guidelines for security aspects like you suggested.  This is a good 
first step, because it means everyone in a little way is responsible for 
security.  "Many eyes."

There are some technical challenges here that we need to deal with like 
the user accounts in packages.  After years of loud yelling, we still 
have not come to any consensus about users used by packaged services. 
The current way relied upon by Core packages is broken and unscalable 
because it relies on a finite small set of userid's.   Arbitrary 
packages can easily clash, or we could simply run out of numbers. 
Enrico tried to address this with the fedora-usermgmt* stuff, but nobody 
understands it and some have actively removed its usage from packages. 
The packaged user problem is something that we need to come to consensus 
on if we are going to move forward with unambiguous written policy.

Unambiguous written policy is the key here.

Warren Togami
wtogami at redhat.com