Vulnerability report process

1

Also, and not only, for the Best Practice badge, we should set up an official vulnerability report process for seL4.

So far, this has simply been by email to one fo the developers. That doesn’t necessarily have to change much, but it needs to be documented.

I propose to set up an email alias that goes to the subset of the technical steering committee that volunteers to be a point of contact for these. We should set up optional encryption for this for people who want to use it.

Any report should get a response within 14 days, and depending on what it is will either go to the bug tracker to be resolved or documented if it can’t/shouldn’t be resolved (e.g. things like Rowhammer), or, if it is for some reason sensitive, will be handled privately with the reporter until it can be made public.

Any thoughts/feedback?

ps: for those who are wondering, why can there be vulnerabilities in verified seL4? Because there are assumptions about the hardware that can be broken, like in Rowhammer, or not used correctly, such as making a mistake with cache coherency, and because there are unverified configurations of seL4 that can have bugs. People often would still like to deploy unverified configurations in systems, and we want to support that with at least the same level of confidence you can have in other well-engineered software.

2

Is this going to be for vulnerabilities in all our repos? Or just the seL4 main repo? We should be very clear as to which repos it applies to.

3

Good question. I was initially thinking about seL4 only, but maybe we should include at least the versioned core repos in the reporting process as well, e.g. capDL and CAmkES. Open to suggestions, though.

(We’re not committing to fixing everything, just to documenting/reacting).

4

Would some kind of “responsible disclosure” process be appropriate? I.e. ask the reporter to keep the report private for a period (90 days or as agreed) to allow remediation, and in return promise to make a good faith effort to remediate within that time frame, and also to give credit.

I guess we’re not in a position to offer bug bounties. :slight_smile:

I could try to draft something along those line, and also tries to characterise what kinds of vulnerabilities it would apply to.

5

Yes, that sounds like a very good idea.

Not currently, no :slight_smile:

That would be awesome!

6

I posted an initial proposal in this pull request:

7

Now merged. Thanks for the help, Matt, I’m very happy with the result!