Fedora Security Response Team Update

[Josh Bressers]

I think it's in the best interest of everyone if I give updates of what's
going on as things happen.  One of my goals is to have a transparent
security team.  This can't happen unless I keep everyone who cares in the
loop.


So far the biggest things done regarding the team are infrastructural
changes.

security(a)fp.o and secalert(a)fp.o aliases have been created and now deliver
mail to a private list.  Right now the only member are Luke Macken and
myself.  I'm not sure how to best hand out membership to this list.  Ideas
are welcome.  It's a matter of trust, and part of the challenge here is who
to trust?

I've also requested a Xen instance for various security tools to run on:
http://fedoraproject.org/wiki/Infrastructure/RFR/wiki/Infrastructure/RFR/...


Things to do:

Update the wiki pages.  The current information is pretty slim.  We'll try
to grow these in an organic manner.  It makes more sense to me if we let
process evolve, and document it, rather than documenting, then trying to
use a process.

GPG key.  I'm pondering how to handle this.  There will be groups that want
to send us encrypted mail.  How can we do this in a secure manner (trust is
a big issue here).

Start the review of FC7.

Task tracking.  How can we do this best?  We theoretically could use
bugzilla, but it's really not ideal for this sort of thing.  There is an
OTRS instance running for the infrastructure group, but I'm afraid when
I'm told it's not used much and could go away.  If we have a Xen instance,
we could run our own RT.  I'm not sure if I like this idea though.

???? (Anything else to add)


-- 
    JB

[Kevin Fenzi]

On Wed, 04 Apr 2007 11:47:40 -0400
Josh Bressers <bressers(a)redhat.com&gt; wrote:

>  I think it's in the best interest of everyone if I give updates
> of
>  what's going on as things happen.  One of my goals is to have a
>  transparent security team.  This can't happen unless I keep everyone
>  who cares in the loop. 
Excellent. I for one appreciate the updates to the list here... 
>  
>  
>  So far the biggest things done regarding the team are infrastructural
>  changes.
>  
>  security(a)fp.o and secalert(a)fp.o aliases have been created and now
>  deliver mail to a private list.  Right now the only member are Luke
>  Macken and myself.  I'm not sure how to best hand out membership to
>  this list.  Ideas are welcome.  It's a matter of trust, and part of
>  the challenge here is who to trust? 
Well, what are those aliases to be used for? 
Folks mailing in vulnerabilties? 
Coordination with other vendors?

>  I've also requested a Xen instance for various security tools to
> run
>  on:
>
> http://fedoraproject.org/wiki/Infrastructure/RFR/wiki/Infrastructure/RFR/...
Sounds good.

>  Things to do:
>  
>  Update the wiki pages.  The current information is pretty slim.
>  We'll try to grow these in an organic manner.  It makes more sense to
>  me if we let process evolve, and document it, rather than
>  documenting, then trying to use a process. 
Agreed. 

>  GPG key.  I'm pondering how to handle this.  There will be
> groups
>  that want to send us encrypted mail.  How can we do this in a secure
>  manner (trust is a big issue here). 
I think it might be good to have a small group (possibly those on the
alias above?) that has the passphrase. They can always foward to this
list anything that would need more general discussion. 

>  Start the review of FC7. 
Fun fun. ;) 

>  Task tracking.  How can we do this best?  We theoretically could use
>  bugzilla, but it's really not ideal for this sort of thing.  There is
>  an OTRS instance running for the infrastructure group, but I'm afraid
>  when I'm told it's not used much and could go away.  If we have a Xen
>  instance, we could run our own RT.  I'm not sure if I like this idea
>  though. 
I think bugzilla is way too heavy. OTRS is also too much in the way. 
How about a wiki page? People can indicate there what chunks they want
to check?

>  ???? (Anything else to add) 
Someone should see about getting at least some folks in the security
team the needed CVS access to be able to fix security issues if the
owner of a package is unavailable. Likewise privs in the build and
updates system to be able to build and push these. Thats all down the
road I'm sure, but something to keep in mind. 

I'm sure there will be more things coming up...

kevin

[Mark Cox]

>  GPG key.  I'm pondering how to handle this.  There will be groups
> that want
>  to send us encrypted mail.  How can we do this in a secure manner (trust is
>  a big issue here). 
So role keys on open source projects are generally a bad idea, and indeed 
both the Apache Software Foundation and OpenSSL security teams do not use 
a role key for secure communications.  In the most part it's just CERT and 
the odd researcher that want secure communications and signing of 
statements.

So what we do in those projects is just tell CERT (and publish on the 
site) the contact details and GPG keys of a few of the security team 
members.   A member on receiving something encrypted has the 
responsibility to triage and pass it on.  Since it doesn't happen often 
(once a month or less) it's not a big deal.

Mark