Date: Mon, 5 Mar 2018 13:08:03 -0800 From: Bryan Drewery <bdrewery@FreeBSD.org> To: cem@freebsd.org, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Proposal: deregulate secteam, random team Message-ID: <49f2eeba-ffb2-11d0-3875-b16a53541a3e@FreeBSD.org> In-Reply-To: <CAG6CVpXAxMJbRpkO510fgyv_NjKK1AitSa_b-0Ff4eknTWmtWQ@mail.gmail.com> References: <CAG6CVpXAxMJbRpkO510fgyv_NjKK1AitSa_b-0Ff4eknTWmtWQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pdQSUFDwUOh4FRakJy9NJ5EHUCNdHS0ea Content-Type: multipart/mixed; boundary="RiSf2BLsV6GI2qbJAUoVv0QWMQzV3w9cQ"; protected-headers="v1" From: Bryan Drewery <bdrewery@FreeBSD.org> To: cem@freebsd.org, "freebsd-arch@freebsd.org" <arch@freebsd.org> Message-ID: <49f2eeba-ffb2-11d0-3875-b16a53541a3e@FreeBSD.org> Subject: Re: Proposal: deregulate secteam, random team References: <CAG6CVpXAxMJbRpkO510fgyv_NjKK1AitSa_b-0Ff4eknTWmtWQ@mail.gmail.com> In-Reply-To: <CAG6CVpXAxMJbRpkO510fgyv_NjKK1AitSa_b-0Ff4eknTWmtWQ@mail.gmail.com> --RiSf2BLsV6GI2qbJAUoVv0QWMQzV3w9cQ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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. --=20 Regards, Bryan Drewery --RiSf2BLsV6GI2qbJAUoVv0QWMQzV3w9cQ-- --pdQSUFDwUOh4FRakJy9NJ5EHUCNdHS0ea Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJanbGzAAoJEDXXcbtuRpfPfUQH/iZgPnHmUG4YK6BiI5hrNFY4 iZHNQ6i1Wu5RtNxuuPxDeWIV5OwkfEWMWVHEeLp+H97/a26ANMHk+DaPyHniKZYE mOq5fkNfQKvba4uTQYxreSeNA07tmJkC21RDoy7ujd6SQ80GQtaL9b9kLfkYPAB2 j/hv8Xy70R6D4srthKMMBA+oogWPKEmpgq8YlzwlYk/TyjTFJcsNhJ0y0IvcypAx UUZyht1lZQVRdvJls7Ah64CVmaaeHUh/lQVuawVtlyrf9Fqdbv+Y6iqnr7phL7vc BXiaHp4pHAQxIgd+Vf7/pAHpBCpfiXrJcPeLNcBR1p6nTFiJYwT8zoBMCGWkxH0= =ot8+ -----END PGP SIGNATURE----- --pdQSUFDwUOh4FRakJy9NJ5EHUCNdHS0ea--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49f2eeba-ffb2-11d0-3875-b16a53541a3e>