Proposal: deregulate secteam, random team

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: deregulate secteam, random team

Conrad Meyer-2
Hi all,

Being on secteam, essentially a post-release engineering team, is a
thankless job no one wants to do.  It's largely keeping quiet about
embargoes and issuing patches and EN to releases.

However, due to a number of factors, our secteam can't seem to operate
effectively.  We struggle to communicate effectively to the wider
FreeBSD organization and the community; we seem unable to reliably
produce patches by the time embargoes lift.  Some factors help explain
this:

1. First and foremost: we're not always getting included in embargoes
anymore.  This is exemplified by the Spectre/Meltdown FUBAR.

2. secteam is tiny and workload tends to alternate suddenly between
"no work" and "everything is on fire."  Are there more than *two*
active members at this time?  No one on secteam is full time.

3. Historical policies about not commenting on active vulns when a
patch was not prepared.  This is just historical stupidity we haven't
managed to leave behind — if a vuln is being exploited in the wild, we
*must* comment on it.  Even if we have to say, "we don't have a
mitigation prepared yet and don't have an ETA."  This kind of policy
makes secteam look not just opaque, but foolish.

4. FreeBSD is dying ;-).

The lack of communication is killer.  Maybe secteam is incredibly
active and efficient, but *no one can tell*, because they have zero
communication with the rest of the project.

Adding on to the burden: for some bizarre reason, we've also foisted
the responsibility of code review of arbitrary parts of the kernel
tree on this post-release engineering team via SVN commit hook.  (And,
segueing into the subject of this email, the random team as well).

Secteam hardly has time to triage security bugs and issue ENs.  Turn
around time on any code review involving secteam is measured in
*weeks* or *months.*

Meanwhile, there is a wide body of security-conscious developers who
are capable of reviewing and evaluating crypto and security code.
They may not be interested in pushing ENs to releases, or their
availability may be irregular.  But they may be motivated to help, and
are totally unable to contribute in the status quo framework.

Furthermore, the review-gating ends up as a big double standard.
Anyone in the outgroup waits weeks on even the most trivial change to
be reviewed, but secteam or random team members are free to jump in
and commit things that breaks the tree with no review.  (Not to name
any names, but, r285422.  And all commits with "Approved by: so
(/dev/random blanket)" in the commit message are examples of this
special privilege, if not a sure sign of breakage.)

I propose deregulating secteam and random team and stripping them of
their review authority.

1. Remove "blocking reviewer" (Phab Herald and svn commit hooks)
status for teams that can't demonstrate consistent, timely review.
That's all of the above mentioned teams.

2. Active pruning of inactive team members.  If membership is too low
to meet the mandate of the teams, *padding the membership with
inactive members does not fix the problem*.

3. Lift access restrictions on security bugzilla to all src
committers.  More security-interested eyeballs can be triaging,
prototyping, reviewing, and evaluating security solutions.

    a. If there are ports security issues tracked in security
bugzilla, access can be extended to relevant porters on a bug-by-bug
person-by-person basis.

4. Maybe just get rid of security bugzilla entirely?  Tracking our
security bug work in the open at least provides transparency, and
maybe transparency helps motivate results.

Flameproof pants on; please go ahead and bikeshed.

Yours,
Conrad
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: deregulate secteam, random team

Conrad Meyer-2
Well, it's unanimous ;-).

What is Core doing about it?

Thanks,
Conrad
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: deregulate secteam, random team

Bryan Drewery-6
In reply to this post by Conrad Meyer-2
On 3/2/2018 11:12 PM, Conrad Meyer wrote:
> 3. Lift access restrictions on security bugzilla to all src
> committers.  More security-interested eyeballs can be triaging,
> prototyping, reviewing, and evaluating security solutions.

I agree with your analysis and that secteam has been a slow broken
blackbox for as long as I can remember.  However I think the 'opening to
all' ideas won't work as we just saw how "trusted" we all really are.
We've had developers compromised before as well.  Getting on
embargoes/NDA will require that we actually have a trusted group of
people who can view these issues.  I think it's one thing to grant all
developers access to Coverity but another to see ones that have been
analysed and reported already.

Anecdotally, I was mailed about a security bug last year and replied
with my suggestions on how to tackle it.  Then a few months ago I was
given access to the bug and effectively it's on me now to fix it.  So
I'm seeing how broken it all is.  I need to make time to address it, but
IMO there is no "security team" that is actively working on bugs.  There
is only effectively a project manager that is herding people to work on
the bugs as needed.  We may have some people there that are respected
for reviews as well.  The slow review problem is very old.  We climbed
uphill to get Pkg and Poudriere deployed and had all of these overly
complex schemes for package signing rather than keeping things simple.
I'm happy with where it is but still think TLS for some of the solutions
would have been simpler for the first implementation.  I don't even
remember anymore what tradeoffs we made in Poudriere to get past a
security review but it was somewhat informal; let's fix things we know
they may complain about (which is good anyway) but in the end I'm not
sure a review was actually done for Poudriere and we just moved forward.
 I forget.  I do know tinderbox underwent a grueling review which
effectively killed it.  I seem to recall for Poudriere that any kind of
web server with a server-side application was verboten by secteam at the
time but that kind of blanket rule was just unhelpful and lazy.  Having
a real design discussion about sandboxing/privsepping a web application
piece and restricting it from using exec() never happened, only a
blanket rule.

I'm saying that I agree that we need a <lot> more people on the team but
we need to be careful about going too far as it may hurt us actually
getting into embargoes.  Secteam has often seemed to me to be 1 person,
maybe 3, who are overly burdened.

I think we could split up some of the roles of secteam though.  I don't
think the security team officer needs to be the one to signoff on every
review.  I think we could easily just have a mailing list of interested
security people who want to review new implementations, like arch@ in a
way.  As for secret bugs that won't work but the right people could
still be brought in as needed.


Lastly the lack of status updates on Meltdown/Spectre is an
embarrassment.  This is not a statement on the implementation or testing
time, but only on the project communication about it.

--
Regards,
Bryan Drewery


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: deregulate secteam, random team

Bryan Drewery-6
On 3/5/2018 1:08 PM, Bryan Drewery wrote:
> I seem to recall for Poudriere that any kind of
> web server with a server-side application was verboten by secteam at the
> time but that kind of blanket rule was just unhelpful and lazy.

I should not have used the word "lazy" here.  I picked a bad word and
should have been more clear that 1 person can never keep up with the
demand and must force compromises like this to move forward.  In the
bigger picture secteam isn't responsible for the cluster systems,
clusteradm is. So clusteradm should be the one to enforce what is
allowed on their systems rather than the security team since they have
to maintain and keep them secure.  The security team should be a
resource for security reviews but not a final say in all regards.

--
Regards,
Bryan Drewery


signature.asc (484 bytes) Download Attachment