content-type: text/plain; charset="utf-8" Subject: Re: [ISC-Bugs #46729] Drop seccomp support X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.pao1.isc.org From: "Mukund Sivaraman" Message-ID: <20171130021615.GA14581@jurassic.lan.banu.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Thu, 30 Nov 2017 07:46:15 +0530 X-Original-To: bind9-public@bugs.isc.org From muks@isc.org Thu Nov 30 02:16:34 2017 X-RT-Incoming-Encryption: Not encrypted References: <20171129152804.GA17965@jurassic.lan.banu.com> X-RT-Interface: Email In-Reply-To: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.1 X-RT-Original-Encoding: utf-8 User-Agent: Mutt/1.9.1 (2017-09-22) Return-Path: To: "Michał Kępień via RT" Content-Disposition: inline Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id 88D74D78B0B for ; Thu, 30 Nov 2017 02:16:34 +0000 (UTC) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by mx.pao1.isc.org (Postfix) with ESMTP id ABD343B27B9 for ; Thu, 30 Nov 2017 02:16:21 +0000 (UTC) Received: from jurassic.lan.banu.com (unknown [115.118.144.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id C853756A0805; Thu, 30 Nov 2017 02:16:18 +0000 (GMT) Delivered-To: bind9-public@bugs.isc.org RT-Message-ID: Content-Length: 1181 On Wed, Nov 29, 2017 at 05:18:40PM +0000, Michał Kępień via RT wrote: > I received an email comment from Loganaden Velvindron, who authored the > patch adding seccomp support to BIND (see RT #35347): > > > Thanks for reaching out. Could we look into a solution where seccomp > > is still kept but as an experimental feature ? > > > > If seccomp is too complex (and I understand the concerns there), how > > about implementing a privilege separation model, and using seccomp > > only for untrusted domains, while avoiding applying it to code paths > > which are less likely to have security issues. FYI, OpenBSD had for a > > long time been running a privilege separated ISC-BIND in their tree. I > > didn't have time to dig into it, but I think that maybe it's time to > > review it, and discuss with the ISC team ? Given the points that were made about (a) syscalls varying depending on underlying library implementation, (b) that we already use syscalls which are bad enough, and (c) there are other ways to achieve similar access control, the feature seems uncontrollable and there doesn't seem to be much advantage in keeping it on as an experimental feature. Mukund