We recently had a couple of security issues, which has made us realise
we need a better process for dealing with these reports, particularly
during the CVE embargo period (while a fix is being written). To
improve this, I'm using this blog entry as a guide:
For our first step, the Redmine upgrade (thanks Greg, Ohad and Sam) has
provided us with the ability to create private issues. These are
visible to Redmine admins (Ohad, Brian, Greg and me) and those with the
new "Security team" role (Sam and Marek). If the issue is assigned to
somebody to write a patch, then they can see it too.
Currently we create a Redmine issue at the time of publishing a fix, so
it isn't very transparent after the event. What I'd like to do is
create an issue while we write and review the fix, then make it public
once the fix is published. We wouldn't use this for anything other than
embargoed security fixes.
For any security issues that are raised to us I suggest we now:
create a private issue issue in Redmine, security category
notify downstream security teams (currently just Red Hat, but others
if we're made aware of them)
request a CVE identifier
review off-list by git send-email etc.
merge the fix and make a new release
make the issue public, so the record of events is available
Later I also wish to set up a better process for receiving security
reports (a dedicated e-mail address) and publishing information
post-release (pages on the website).
> From: "Dominic Cleal" <dcleal@redhat.com>
> To: "foreman-dev" <foreman-dev@googlegroups.com>
> Sent: Monday, July 29, 2013 2:29:49 PM
> Subject: [foreman-dev] Redmine security process
>
> We recently had a couple of security issues, which has made us realise
> we need a better process for dealing with these reports, particularly
> during the CVE embargo period (while a fix is being written). To
> improve this, I'm using this blog entry as a guide:
>
> http://securityblog.redhat.com/2013/01/30/a-minimal-security-response-process/
>
> For our first step, the Redmine upgrade (thanks Greg, Ohad and Sam) has
> provided us with the ability to create private issues. These are
> visible to Redmine admins (Ohad, Brian, Greg and me) and those with the
> new "Security team" role (Sam and Marek). If the issue is assigned to
> somebody to write a patch, then they can see it too.
>
> Currently we create a Redmine issue at the time of publishing a fix, so
> it isn't very transparent after the event. What I'd like to do is
> create an issue while we write and review the fix, then make it public
> once the fix is published. We wouldn't use this for anything other than
> embargoed security fixes.
This sounds like a good plan. It also provides some nice transparency into the process for people who submit security issues later.
>
> For any security issues that are raised to us I suggest we now:
> 1) create a private issue issue in Redmine, security category
> 2) notify downstream security teams (currently just Red Hat, but others
> if we're made aware of them)
> 3) request a CVE identifier
> 4) review off-list by git send-email etc.
> 5) merge the fix and make a new release
> 6) make the issue public, so the record of events is available
>
> Later I also wish to set up a better process for receiving security
> reports (a dedicated e-mail address) and publishing information
> post-release (pages on the website).
Since we now have a MTA that runs on our infrastructure we can use that distribute mail about security issues to Marek and myself. I think it'd be ideal to have an issue coordinator who talks with the person who reported the issue. Here's what the process would ideally look like:
Some finds a vulnerability.
They send a GPG signed email to security@theforeman.org (or whatever email) saying they have found an issue. They do not send the actual issue.
A member of the security teams replies with a signed message asking for them to send an encrypted message back with the issue.
The issue gets put into Redmine and marked as private, a CVE is requested from Red Hat SRT (they're a big CNA).
A patch is written and tested.
The patch gets publicly released, disclosed, and the CVE has a description associated with it.
This obviously relies on the reporter having GPG setup on their machine. Is that too high an average bar for us to set to report an issue? If not, what do we do in cases where someone doesn't have GPG set up?
>
>
> > From: "Dominic Cleal" <dcleal@redhat.com>
> > To: "foreman-dev" <foreman-dev@googlegroups.com>
> > Sent: Monday, July 29, 2013 2:29:49 PM
> > Subject: [foreman-dev] Redmine security process
> >
> > We recently had a couple of security issues, which has made us realise
> > we need a better process for dealing with these reports, particularly
> > during the CVE embargo period (while a fix is being written). To
> > improve this, I'm using this blog entry as a guide:
> >
> > http://securityblog.redhat.com/2013/01/30/a-minimal-security-response-process/
> >
> > For our first step, the Redmine upgrade (thanks Greg, Ohad and Sam) has
> > provided us with the ability to create private issues. These are
> > visible to Redmine admins (Ohad, Brian, Greg and me) and those with the
> > new "Security team" role (Sam and Marek). If the issue is assigned to
> > somebody to write a patch, then they can see it too.
> >
> > Currently we create a Redmine issue at the time of publishing a fix, so
> > it isn't very transparent after the event. What I'd like to do is
> > create an issue while we write and review the fix, then make it public
> > once the fix is published. We wouldn't use this for anything other than
> > embargoed security fixes.
>
> This sounds like a good plan. It also provides some nice transparency into the process for people who submit security issues later.
>
> >
> > For any security issues that are raised to us I suggest we now:
> > 1) create a private issue issue in Redmine, security category
> > 2) notify downstream security teams (currently just Red Hat, but others
> > if we're made aware of them)
> > 3) request a CVE identifier
> > 4) review off-list by git send-email etc.
> > 5) merge the fix and make a new release
> > 6) make the issue public, so the record of events is available
> >
> > Later I also wish to set up a better process for receiving security
> > reports (a dedicated e-mail address) and publishing information
> > post-release (pages on the website).
>
> Since we now have a MTA that runs on our infrastructure we can use that distribute mail about security issues to Marek and myself. I think it'd be ideal to have an issue coordinator who talks with the person who reported the issue. Here's what the process would ideally look like:
>
> 1. Some finds a vulnerability.
> 2. They send a GPG signed email to security@theforeman.org (or whatever email) saying they have found an issue. They do not send the actual issue.
Can't you publish a GPG public key for security@theforeman.org so people
can send the actual issue encryped?
> 3. A member of the security teams replies with a signed message asking for them to send an encrypted message back with the issue.
> 4. The issue gets put into Redmine and marked as private, a CVE is requested from Red Hat SRT (they're a big CNA).
> 5. A patch is written and tested.
> 6. The patch gets publicly released, disclosed, and the CVE has a description associated with it.
>
> This obviously relies on the reporter having GPG setup on their machine. Is that too high an average bar for us to set to report an issue? If not, what do we do in cases where someone doesn't have GPG set up?
I think you should do both, given GPG isn't all that easy for everyone
and you want to make reporting security issues as inviting as possible.
···
On Mon, Jul 29, 2013 at 02:41:28PM -0400, Sam Kottler wrote:
> ----- Original Message -----
>
> > From: "Sam Kottler" <skottler@redhat.com>
> > To: foreman-dev@googlegroups.com
> > Sent: Monday, July 29, 2013 4:02:40 PM
> > Subject: Re: [foreman-dev] Redmine security process
> >
> >
> >
> >
> > > From: "Ewoud Kohl van Wijngaarden" <ewoud@kohlvanwijngaarden.nl>
> > > To: foreman-dev@googlegroups.com
> > > Sent: Monday, July 29, 2013 3:56:46 PM
> > > Subject: Re: [foreman-dev] Redmine security process
> > >
> > > >
> > > > > From: "Dominic Cleal" <dcleal@redhat.com>
> > > > > To: "foreman-dev" <foreman-dev@googlegroups.com>
> > > > > Sent: Monday, July 29, 2013 2:29:49 PM
> > > > > Subject: [foreman-dev] Redmine security process
> > > > >
> > > > > We recently had a couple of security issues, which has made us
> > > > > realise
> > > > > we need a better process for dealing with these reports,
> > > > > particularly
> > > > > during the CVE embargo period (while a fix is being written). To
> > > > > improve this, I'm using this blog entry as a guide:
> > > > >
> > > > > http://securityblog.redhat.com/2013/01/30/a-minimal-security-respons
> > > > > e-process/
> > > > >
> > > > > For our first step, the Redmine upgrade (thanks Greg, Ohad and Sam)
> > > > > has
> > > > > provided us with the ability to create private issues. These are
> > > > > visible to Redmine admins (Ohad, Brian, Greg and me) and those with
> > > > > the
> > > > > new "Security team" role (Sam and Marek). If the issue is assigned
> > > > > to
> > > > > somebody to write a patch, then they can see it too.
> > > > >
> > > > > Currently we create a Redmine issue at the time of publishing a fix,
> > > > > so
> > > > > it isn't very transparent after the event. What I'd like to do is
> > > > > create an issue while we write and review the fix, then make it
> > > > > public
> > > > > once the fix is published. We wouldn't use this for anything other
> > > > > than
> > > > > embargoed security fixes.
> > > >
> > > > This sounds like a good plan. It also provides some nice transparency
> > > > into
> > > > the process for people who submit security issues later.
> > > >
> > > > > For any security issues that are raised to us I suggest we now:
> > > > > 1) create a private issue issue in Redmine, security category
> > > > > 2) notify downstream security teams (currently just Red Hat, but
> > > > > others
> > > > > if we're made aware of them)
> > > > > 3) request a CVE identifier
> > > > > 4) review off-list by git send-email etc.
> > > > > 5) merge the fix and make a new release
> > > > > 6) make the issue public, so the record of events is available
> > > > >
> > > > > Later I also wish to set up a better process for receiving security
> > > > > reports (a dedicated e-mail address) and publishing information
> > > > > post-release (pages on the website).
> > > >
> > > > Since we now have a MTA that runs on our infrastructure we can use
> > > > that
> > > > distribute mail about security issues to Marek and myself. I think
> > > > it'd
> > > > be
> > > > ideal to have an issue coordinator who talks with the person who
> > > > reported
> > > > the issue. Here's what the process would ideally look like:
> > > >
> > > > 1. Some finds a vulnerability.
> > > > 2. They send a GPG signed email to security@theforeman.org (or
> > > > whatever
> > > > email) saying they have found an issue. They do not send the actual
> > > > issue.
> > >
> > > Can't you publish a GPG public key for security@theforeman.org so people
> > > can send the actual issue encryped?
> >
> > Under the scheme that I outlined they will still send an encrypted email,
> > it'll just be to the person who responded to them. If we use a cert that's
> > shared between users then we'll have to revoke it when individuals with
> > access to it stop working on the project.
There's one small problem with GPG - a trust. How user could know that the key
is really mine? Maybe sign by some security@theforeman.org key? Or just the
fact that someone answers on message sent to security@ is sufficient?
Another already mentioned thing is that not every user has his GPG key and his
mail client setup. I think we could leverage redmine for this. User can create
private issue even when he does not have permission to read it. I think casual
redmine user can see private issue only in case it's assigned to him. We'd
need to secure redmine with HTTPS.
···
> ----- Original Message -----
> > ----- Original Message -----
> > > On Mon, Jul 29, 2013 at 02:41:28PM -0400, Sam Kottler wrote:
> > > > ----- Original Message -----
s/cert/key
A member of the security teams replies with a signed message asking
for
them to send an encrypted message back with the issue.
The issue gets put into Redmine and marked as private, a CVE is
requested from Red Hat SRT (they’re a big CNA).
A patch is written and tested.
The patch gets publicly released, disclosed, and the CVE has a
description associated with it.
This obviously relies on the reporter having GPG setup on their
machine.
Is
that too high an average bar for us to set to report an issue? If not,
what do we do in cases where someone doesn’t have GPG set up?
I think you should do both, given GPG isn’t all that easy for everyone
and you want to make reporting security issues as inviting as possible.
Right, I agree. I guess I was asking what the non-GPG side of "both"
should
be
It's a nice-to-have, but we can't assume everybody does or will use it,
for whatever reason. I don't think we can require it, just recommend it.
···
On 29/07/13 19:41, Sam Kottler wrote:
>
>
> ----- Original Message -----
>> From: "Dominic Cleal"
>> To: "foreman-dev"
>> Sent: Monday, July 29, 2013 2:29:49 PM
>> Subject: [foreman-dev] Redmine security process
>> [..]
>> Later I also wish to set up a better process for receiving security
>> reports (a dedicated e-mail address) and publishing information
>> post-release (pages on the website).
>
> Since we now have a MTA that runs on our infrastructure we can use that distribute mail about security issues to Marek and myself. I think it'd be ideal to have an issue coordinator who talks with the person who reported the issue. Here's what the process would ideally look like:
>
> 1. Some finds a vulnerability.
> 2. They send a GPG signed email to security@theforeman.org (or whatever email) saying they have found an issue. They *do not* send the actual issue.
> 3. A member of the security teams replies with a signed message asking for them to send an encrypted message back with the issue.
> 4. The issue gets put into Redmine and marked as private, a CVE is requested from Red Hat SRT (they're a big CNA).
> 5. A patch is written and tested.
> 6. The patch gets publicly released, disclosed, and the CVE has a description associated with it.
>
> This obviously relies on the reporter having GPG setup on their machine. Is that too high an average bar for us to set to report an issue? If not, what do we do in cases where someone doesn't have GPG set up?
> From: "Ewoud Kohl van Wijngaarden" <ewoud@kohlvanwijngaarden.nl>
> To: foreman-dev@googlegroups.com
> Sent: Monday, July 29, 2013 3:56:46 PM
> Subject: Re: [foreman-dev] Redmine security process
>
> >
> >
> > > From: "Dominic Cleal" <dcleal@redhat.com>
> > > To: "foreman-dev" <foreman-dev@googlegroups.com>
> > > Sent: Monday, July 29, 2013 2:29:49 PM
> > > Subject: [foreman-dev] Redmine security process
> > >
> > > We recently had a couple of security issues, which has made us realise
> > > we need a better process for dealing with these reports, particularly
> > > during the CVE embargo period (while a fix is being written). To
> > > improve this, I'm using this blog entry as a guide:
> > >
> > > http://securityblog.redhat.com/2013/01/30/a-minimal-security-response-process/
> > >
> > > For our first step, the Redmine upgrade (thanks Greg, Ohad and Sam) has
> > > provided us with the ability to create private issues. These are
> > > visible to Redmine admins (Ohad, Brian, Greg and me) and those with the
> > > new "Security team" role (Sam and Marek). If the issue is assigned to
> > > somebody to write a patch, then they can see it too.
> > >
> > > Currently we create a Redmine issue at the time of publishing a fix, so
> > > it isn't very transparent after the event. What I'd like to do is
> > > create an issue while we write and review the fix, then make it public
> > > once the fix is published. We wouldn't use this for anything other than
> > > embargoed security fixes.
> >
> > This sounds like a good plan. It also provides some nice transparency into
> > the process for people who submit security issues later.
> >
> > >
> > > For any security issues that are raised to us I suggest we now:
> > > 1) create a private issue issue in Redmine, security category
> > > 2) notify downstream security teams (currently just Red Hat, but others
> > > if we're made aware of them)
> > > 3) request a CVE identifier
> > > 4) review off-list by git send-email etc.
> > > 5) merge the fix and make a new release
> > > 6) make the issue public, so the record of events is available
> > >
> > > Later I also wish to set up a better process for receiving security
> > > reports (a dedicated e-mail address) and publishing information
> > > post-release (pages on the website).
> >
> > Since we now have a MTA that runs on our infrastructure we can use that
> > distribute mail about security issues to Marek and myself. I think it'd be
> > ideal to have an issue coordinator who talks with the person who reported
> > the issue. Here's what the process would ideally look like:
> >
> > 1. Some finds a vulnerability.
> > 2. They send a GPG signed email to security@theforeman.org (or whatever
> > email) saying they have found an issue. They do not send the actual
> > issue.
>
> Can't you publish a GPG public key for security@theforeman.org so people
> can send the actual issue encryped?
Under the scheme that I outlined they will still send an encrypted email, it'll just be to the person who responded to them. If we use a cert that's shared between users then we'll have to revoke it when individuals with access to it stop working on the project.
>
> > 3. A member of the security teams replies with a signed message asking for
> > them to send an encrypted message back with the issue.
> > 4. The issue gets put into Redmine and marked as private, a CVE is
> > requested from Red Hat SRT (they're a big CNA).
> > 5. A patch is written and tested.
> > 6. The patch gets publicly released, disclosed, and the CVE has a
> > description associated with it.
> >
> > This obviously relies on the reporter having GPG setup on their machine. Is
> > that too high an average bar for us to set to report an issue? If not,
> > what do we do in cases where someone doesn't have GPG set up?
>
> I think you should do both, given GPG isn't all that easy for everyone
> and you want to make reporting security issues as inviting as possible.
Right, I agree. I guess I was asking what the non-GPG side of "both" should be
···
----- Original Message -----
> On Mon, Jul 29, 2013 at 02:41:28PM -0400, Sam Kottler wrote:
> > ----- Original Message -----
> From: "Sam Kottler" <skottler@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Monday, July 29, 2013 4:02:40 PM
> Subject: Re: [foreman-dev] Redmine security process
>
>
>
> > From: "Ewoud Kohl van Wijngaarden" <ewoud@kohlvanwijngaarden.nl>
> > To: foreman-dev@googlegroups.com
> > Sent: Monday, July 29, 2013 3:56:46 PM
> > Subject: Re: [foreman-dev] Redmine security process
> >
> > >
> > >
> > > > From: "Dominic Cleal" <dcleal@redhat.com>
> > > > To: "foreman-dev" <foreman-dev@googlegroups.com>
> > > > Sent: Monday, July 29, 2013 2:29:49 PM
> > > > Subject: [foreman-dev] Redmine security process
> > > >
> > > > We recently had a couple of security issues, which has made us realise
> > > > we need a better process for dealing with these reports, particularly
> > > > during the CVE embargo period (while a fix is being written). To
> > > > improve this, I'm using this blog entry as a guide:
> > > >
> > > > http://securityblog.redhat.com/2013/01/30/a-minimal-security-response-process/
> > > >
> > > > For our first step, the Redmine upgrade (thanks Greg, Ohad and Sam) has
> > > > provided us with the ability to create private issues. These are
> > > > visible to Redmine admins (Ohad, Brian, Greg and me) and those with the
> > > > new "Security team" role (Sam and Marek). If the issue is assigned to
> > > > somebody to write a patch, then they can see it too.
> > > >
> > > > Currently we create a Redmine issue at the time of publishing a fix, so
> > > > it isn't very transparent after the event. What I'd like to do is
> > > > create an issue while we write and review the fix, then make it public
> > > > once the fix is published. We wouldn't use this for anything other
> > > > than
> > > > embargoed security fixes.
> > >
> > > This sounds like a good plan. It also provides some nice transparency
> > > into
> > > the process for people who submit security issues later.
> > >
> > > >
> > > > For any security issues that are raised to us I suggest we now:
> > > > 1) create a private issue issue in Redmine, security category
> > > > 2) notify downstream security teams (currently just Red Hat, but others
> > > > if we're made aware of them)
> > > > 3) request a CVE identifier
> > > > 4) review off-list by git send-email etc.
> > > > 5) merge the fix and make a new release
> > > > 6) make the issue public, so the record of events is available
> > > >
> > > > Later I also wish to set up a better process for receiving security
> > > > reports (a dedicated e-mail address) and publishing information
> > > > post-release (pages on the website).
> > >
> > > Since we now have a MTA that runs on our infrastructure we can use that
> > > distribute mail about security issues to Marek and myself. I think it'd
> > > be
> > > ideal to have an issue coordinator who talks with the person who reported
> > > the issue. Here's what the process would ideally look like:
> > >
> > > 1. Some finds a vulnerability.
> > > 2. They send a GPG signed email to security@theforeman.org (or whatever
> > > email) saying they have found an issue. They do not send the actual
> > > issue.
> >
> > Can't you publish a GPG public key for security@theforeman.org so people
> > can send the actual issue encryped?
>
> Under the scheme that I outlined they will still send an encrypted email,
> it'll just be to the person who responded to them. If we use a cert that's
> shared between users then we'll have to revoke it when individuals with
> access to it stop working on the project.
s/cert/key
···
----- Original Message -----
> ----- Original Message -----
> > On Mon, Jul 29, 2013 at 02:41:28PM -0400, Sam Kottler wrote:
> > > ----- Original Message -----
A member of the security teams replies with a signed message asking
for
them to send an encrypted message back with the issue.
The issue gets put into Redmine and marked as private, a CVE is
requested from Red Hat SRT (they’re a big CNA).
A patch is written and tested.
The patch gets publicly released, disclosed, and the CVE has a
description associated with it.
This obviously relies on the reporter having GPG setup on their machine.
Is
that too high an average bar for us to set to report an issue? If not,
what do we do in cases where someone doesn’t have GPG set up?
I think you should do both, given GPG isn’t all that easy for everyone
and you want to make reporting security issues as inviting as possible.
Right, I agree. I guess I was asking what the non-GPG side of “both” should
be
> From: "Marek Hulan" <mhulan@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Tuesday, July 30, 2013 2:04:29 AM
> Subject: Re: [foreman-dev] Redmine security process
>
> >
> > > From: "Sam Kottler" <skottler@redhat.com>
> > > To: foreman-dev@googlegroups.com
> > > Sent: Monday, July 29, 2013 4:02:40 PM
> > > Subject: Re: [foreman-dev] Redmine security process
> > >
> > >
> > >
> > >
> > > > From: "Ewoud Kohl van Wijngaarden" <ewoud@kohlvanwijngaarden.nl>
> > > > To: foreman-dev@googlegroups.com
> > > > Sent: Monday, July 29, 2013 3:56:46 PM
> > > > Subject: Re: [foreman-dev] Redmine security process
> > > >
> > > > >
> > > > > > From: "Dominic Cleal" <dcleal@redhat.com>
> > > > > > To: "foreman-dev" <foreman-dev@googlegroups.com>
> > > > > > Sent: Monday, July 29, 2013 2:29:49 PM
> > > > > > Subject: [foreman-dev] Redmine security process
> > > > > >
> > > > > > We recently had a couple of security issues, which has made us
> > > > > > realise
> > > > > > we need a better process for dealing with these reports,
> > > > > > particularly
> > > > > > during the CVE embargo period (while a fix is being written). To
> > > > > > improve this, I'm using this blog entry as a guide:
> > > > > >
> > > > > > http://securityblog.redhat.com/2013/01/30/a-minimal-security-respons
> > > > > > e-process/
> > > > > >
> > > > > > For our first step, the Redmine upgrade (thanks Greg, Ohad and Sam)
> > > > > > has
> > > > > > provided us with the ability to create private issues. These are
> > > > > > visible to Redmine admins (Ohad, Brian, Greg and me) and those with
> > > > > > the
> > > > > > new "Security team" role (Sam and Marek). If the issue is assigned
> > > > > > to
> > > > > > somebody to write a patch, then they can see it too.
> > > > > >
> > > > > > Currently we create a Redmine issue at the time of publishing a
> > > > > > fix,
> > > > > > so
> > > > > > it isn't very transparent after the event. What I'd like to do is
> > > > > > create an issue while we write and review the fix, then make it
> > > > > > public
> > > > > > once the fix is published. We wouldn't use this for anything other
> > > > > > than
> > > > > > embargoed security fixes.
> > > > >
> > > > > This sounds like a good plan. It also provides some nice transparency
> > > > > into
> > > > > the process for people who submit security issues later.
> > > > >
> > > > > > For any security issues that are raised to us I suggest we now:
> > > > > > 1) create a private issue issue in Redmine, security category
> > > > > > 2) notify downstream security teams (currently just Red Hat, but
> > > > > > others
> > > > > > if we're made aware of them)
> > > > > > 3) request a CVE identifier
> > > > > > 4) review off-list by git send-email etc.
> > > > > > 5) merge the fix and make a new release
> > > > > > 6) make the issue public, so the record of events is available
> > > > > >
> > > > > > Later I also wish to set up a better process for receiving security
> > > > > > reports (a dedicated e-mail address) and publishing information
> > > > > > post-release (pages on the website).
> > > > >
> > > > > Since we now have a MTA that runs on our infrastructure we can use
> > > > > that
> > > > > distribute mail about security issues to Marek and myself. I think
> > > > > it'd
> > > > > be
> > > > > ideal to have an issue coordinator who talks with the person who
> > > > > reported
> > > > > the issue. Here's what the process would ideally look like:
> > > > >
> > > > > 1. Some finds a vulnerability.
> > > > > 2. They send a GPG signed email to security@theforeman.org (or
> > > > > whatever
> > > > > email) saying they have found an issue. They do not send the actual
> > > > > issue.
> > > >
> > > > Can't you publish a GPG public key for security@theforeman.org so
> > > > people
> > > > can send the actual issue encryped?
> > >
> > > Under the scheme that I outlined they will still send an encrypted email,
> > > it'll just be to the person who responded to them. If we use a cert
> > > that's
> > > shared between users then we'll have to revoke it when individuals with
> > > access to it stop working on the project.
>
> There's one small problem with GPG - a trust. How user could know that the
> key
> is really mine? Maybe sign by some security@theforeman.org key? Or just the
> fact that someone answers on message sent to security@ is sufficient?
I think the implicit security that comes with someone replying to you after emailing an address is fine.
>
> Another already mentioned thing is that not every user has his GPG key and
> his
> mail client setup. I think we could leverage redmine for this. User can
> create
> private issue even when he does not have permission to read it. I think
> casual
> redmine user can see private issue only in case it's assigned to him. We'd
> need to secure redmine with HTTPS.
I wonder if there's a redmine plugin that let's you submit issues privately into a queue for review. Then you and I can go through that and find relevant issues to create private issues.
···
----- Original Message -----
> > ----- Original Message -----
> > > ----- Original Message -----
> > > > On Mon, Jul 29, 2013 at 02:41:28PM -0400, Sam Kottler wrote:
> > > > > ----- Original Message -----
s/cert/key
A member of the security teams replies with a signed message
asking
for
them to send an encrypted message back with the issue.
The issue gets put into Redmine and marked as private, a CVE is
requested from Red Hat SRT (they’re a big CNA).
A patch is written and tested.
The patch gets publicly released, disclosed, and the CVE has a
description associated with it.
This obviously relies on the reporter having GPG setup on their
machine.
Is
that too high an average bar for us to set to report an issue? If
not,
what do we do in cases where someone doesn’t have GPG set up?
I think you should do both, given GPG isn’t all that easy for everyone
and you want to make reporting security issues as inviting as possible.
Right, I agree. I guess I was asking what the non-GPG side of "both"
should
be
There is a permission we can grant in Redmine that lets users change the
private flag on their own issues, so they could set it when submitting
an issue. I'm a bit worried that people might forget though, so I
prefer e-mail.
I was also looking at ways to automatically set the private flag on any
issues that are in the security category, or filed in a security
tracker, but I think this too would be error-prone if we relied on it.
···
On 30/07/13 14:38, Sam Kottler wrote:
>
>
> ----- Original Message -----
>> From: "Marek Hulan"
>> To: foreman-dev@googlegroups.com
>> Sent: Tuesday, July 30, 2013 2:04:29 AM
>> Subject: Re: [foreman-dev] Redmine security process
>>
>> Another already mentioned thing is that not every user has his GPG key and
>> his
>> mail client setup. I think we could leverage redmine for this. User can
>> create
>> private issue even when he does not have permission to read it. I think
>> casual
>> redmine user can see private issue only in case it's assigned to him. We'd
>> need to secure redmine with HTTPS.
>
> I wonder if there's a redmine plugin that let's you submit issues privately into a queue for review. Then you and I can go through that and find relevant issues to create private issues.
Not sure if this is what you want but you can filter issues that are private
and in status new for example. Or we can have separate tracker for those, that
gets created by us.
···
On Tuesday 30 of July 2013 09:38:39 Sam Kottler wrote:
> ----- Original Message -----
>
> > From: "Marek Hulan"
> > To: foreman-dev@googlegroups.com
> > Sent: Tuesday, July 30, 2013 2:04:29 AM
> > Subject: Re: [foreman-dev] Redmine security process
> >
> > > ----- Original Message -----
> > >
> > > > From: "Sam Kottler"
> > > > To: foreman-dev@googlegroups.com
> > > > Sent: Monday, July 29, 2013 4:02:40 PM
> > > > Subject: Re: [foreman-dev] Redmine security process
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > >
> > > > > From: "Ewoud Kohl van Wijngaarden"
> > > > > To: foreman-dev@googlegroups.com
> > > > > Sent: Monday, July 29, 2013 3:56:46 PM
> > > > > Subject: Re: [foreman-dev] Redmine security process
> > > > >
> > > > > On Mon, Jul 29, 2013 at 02:41:28PM -0400, Sam Kottler wrote:
> > > > > > ----- Original Message -----
> > > > > >
> > > > > > > From: "Dominic Cleal"
> > > > > > > To: "foreman-dev"
> > > > > > > Sent: Monday, July 29, 2013 2:29:49 PM
> > > > > > > Subject: [foreman-dev] Redmine security process
> > > > > > >
> > > > > > > We recently had a couple of security issues, which has made us
> > > > > > > realise
> > > > > > > we need a better process for dealing with these reports,
> > > > > > > particularly
> > > > > > > during the CVE embargo period (while a fix is being written).
> > > > > > > To
> > > > > > > improve this, I'm using this blog entry as a guide:
> > > > > > >
> > > > > > > http://securityblog.redhat.com/2013/01/30/a-minimal-security-res
> > > > > > > pons
> > > > > > > e-process/
> > > > > > >
> > > > > > > For our first step, the Redmine upgrade (thanks Greg, Ohad and
> > > > > > > Sam)
> > > > > > > has
> > > > > > > provided us with the ability to create private issues. These
> > > > > > > are
> > > > > > > visible to Redmine admins (Ohad, Brian, Greg and me) and those
> > > > > > > with
> > > > > > > the
> > > > > > > new "Security team" role (Sam and Marek). If the issue is
> > > > > > > assigned
> > > > > > > to
> > > > > > > somebody to write a patch, then they can see it too.
> > > > > > >
> > > > > > > Currently we create a Redmine issue at the time of publishing a
> > > > > > > fix,
> > > > > > > so
> > > > > > > it isn't very transparent after the event. What I'd like to do
> > > > > > > is
> > > > > > > create an issue while we write and review the fix, then make it
> > > > > > > public
> > > > > > > once the fix is published. We wouldn't use this for anything
> > > > > > > other
> > > > > > > than
> > > > > > > embargoed security fixes.
> > > > > >
> > > > > > This sounds like a good plan. It also provides some nice
> > > > > > transparency
> > > > > > into
> > > > > > the process for people who submit security issues later.
> > > > > >
> > > > > > > For any security issues that are raised to us I suggest we now:
> > > > > > > 1) create a private issue issue in Redmine, security category
> > > > > > > 2) notify downstream security teams (currently just Red Hat, but
> > > > > > > others
> > > > > > > if we're made aware of them)
> > > > > > > 3) request a CVE identifier
> > > > > > > 4) review off-list by git send-email etc.
> > > > > > > 5) merge the fix and make a new release
> > > > > > > 6) make the issue public, so the record of events is available
> > > > > > >
> > > > > > > Later I also wish to set up a better process for receiving
> > > > > > > security
> > > > > > > reports (a dedicated e-mail address) and publishing information
> > > > > > > post-release (pages on the website).
> > > > > >
> > > > > > Since we now have a MTA that runs on our infrastructure we can use
> > > > > > that
> > > > > > distribute mail about security issues to Marek and myself. I think
> > > > > > it'd
> > > > > > be
> > > > > > ideal to have an issue coordinator who talks with the person who
> > > > > > reported
> > > > > > the issue. Here's what the process would ideally look like:
> > > > > >
> > > > > > 1. Some finds a vulnerability.
> > > > > > 2. They send a GPG signed email to security@theforeman.org (or
> > > > > > whatever
> > > > > > email) saying they have found an issue. They *do not* send the
> > > > > > actual
> > > > > > issue.
> > > > >
> > > > > Can't you publish a GPG public key for security@theforeman.org so
> > > > > people
> > > > > can send the actual issue encryped?
> > > >
> > > > Under the scheme that I outlined they will still send an encrypted
> > > > email,
> > > > it'll just be to the person who responded to them. If we use a cert
> > > > that's
> > > > shared between users then we'll have to revoke it when individuals
> > > > with
> > > > access to it stop working on the project.
> >
> > There's one small problem with GPG - a trust. How user could know that the
> > key
> > is really mine? Maybe sign by some security@theforeman.org key? Or just
> > the
> > fact that someone answers on message sent to security@ is sufficient?
>
> I think the implicit security that comes with someone replying to you after
> emailing an address is fine.
> > Another already mentioned thing is that not every user has his GPG key and
> > his
> > mail client setup. I think we could leverage redmine for this. User can
> > create
> > private issue even when he does not have permission to read it. I think
> > casual
> > redmine user can see private issue only in case it's assigned to him. We'd
> > need to secure redmine with HTTPS.
>
> I wonder if there's a redmine plugin that let's you submit issues privately
> into a queue for review. Then you and I can go through that and find
> relevant issues to create private issues.
–
Marek
s/cert/key
A member of the security teams replies with a signed message
asking
for
them to send an encrypted message back with the issue.
The issue gets put into Redmine and marked as private, a CVE is
requested from Red Hat SRT (they’re a big CNA).
A patch is written and tested.
The patch gets publicly released, disclosed, and the CVE has a
description associated with it.
This obviously relies on the reporter having GPG setup on their
machine.
Is
that too high an average bar for us to set to report an issue? If
not,
what do we do in cases where someone doesn’t have GPG set up?
I think you should do both, given GPG isn’t all that easy for
everyone
and you want to make reporting security issues as inviting as
possible.
Right, I agree. I guess I was asking what the non-GPG side of "both"
should
be
