[ovs-dev] [PATCH RFC] SECURITY: New document describing proposed security process for OVS.

[Ben Pfaff]

On Mon, Jan 05, 2015 at 04:23:59PM +0100, Jiri Benc wrote:
> On Fri, 2 Jan 2015 17:57:14 -0800, Ben Pfaff wrote:
> >     1) Consider provisions for ensuring privacy and integrity of
> >     communications around disclosure (eg, use PGP for all comms).
> 
> That never hurts. I'd argue that's not strictly required though, as the
> code speaks for itself and anybody can verify the patch does what it
> does and the reasoning is correct.

I'm in favor, obviously, of privacy and integrity of communications, but
I do not know how it works out practically.  Is there a good way to
ensure end-to-end privacy and integrity when emailing a mailing list?
And if so, what is the chance that people reporting vulnerabilities know
how to do this and have the correct software for it?

One option would be for reporters to send an encrypted email to some
individual in the security team--e.g. to me since I'm in the Debian
web-of-trust or to Jesse or Pravin since they're in the kernel
web-of-trust--but then that individual would just have the same problem
for distributing the information to the rest of the team.

> >     2) Consider provisions for handling the vuln info to prevent it from
> >     being leaked / stolen from developers (this info can often be worth a
> >     lot of money to certain parties with a lot of interest and motivation to
> >     get hold of them). This means keeping info in some sort of secured
> >     enclaves, and perhaps mixing patch code with other commits to obfuscate
> >     the presence of the flaw.
> 
> I strongly disagree with that. Distributions need to be able to cherry
> pick the security fixes, any kind of obfuscation and mixing commits for
> different things makes the life of distro maintainers harder, leading
> to more mistakes, thus less security for those who use ovs via a
> distro. Such thing would not improve security of the ovs project anyway
> --the yet undiscovered bugs do not have a patch to obfuscate, and
> discovered and patched bugs are, well, patched. Anybody running on the
> latest code base has the fix applied; for backports, a clear patch to
> backport is needed.

This would almost make sense *before* release of embargo, but again I
can't imagine it working out practically.  I'm not going to spend tons
of time on writing up a bunch of red herring commits.  I don't know what
an "secured enclave" is; if it means maintaining a separate "more
secure" office or computer or whatever, the overhead is too high.

> >     Parts of OVS are in kernel space, making it a
> >     quite an “interesting” target, so I wouldn’t take this one lightly.
> 
> The kernel patches will need to go through the kernel security
> reporting process:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SecurityBugs
> 
> Which is maybe a good idea to include in the documentation?

Good idea.

I added the following paragraph under "Reception":

    The Linux kernel has its own vulnerability management process:
    https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SecurityBugs
    Handling of vulnerabilities that affect both the Open vSwitch tree and
    the upstream Linux kernel should be reported through both processes.
    Please send your report as a single email to both the kernel and OVS
    security teams to allow those teams to most easily coordinate among
    themselves.

> >     3) Consider revising patch release process to ensure patched code
> >     reaches deployments without disclosing the vulnerability; and release
> >     the vuln info after allowing sufficient time for fixed code to percolate
> >     into running environments. Currently proposed process does not appear to
> >     allow for this.
> 
> It does, through the embargoed disclosure. Committing the patch without
> sending it to ovs-dev list and releasing the disclosure only later does
> not make sense. It would draw the attention to the fix anyway. And
> sending it for review to ovs-dev without telling what the patch fixes
> won't work, either.
> 
> Overall, these suggestions seem to be from somebody who's not familiar
> with how open source development works.

Could be, I don't think I know him.