X-Scanned-BY: MIMEDefang 2.68 on 10.5.11.27 CC: bind9-bugs@isc.org MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 In-Reply-To: <1692671561.23269505.1408495501961.JavaMail.zimbra@redhat.com> References: <53F36A3B.1000109@redhat.com> <1692671561.23269505.1408495501961.JavaMail.zimbra@redhat.com> content-type: text/plain; charset="utf-8" Message-ID: <2512682.Pi8ZBlN7Bd@sifl> Organization: Red Hat Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by bugs.isc.org (Postfix) with ESMTP id 806222D20571 for ; Wed, 20 Aug 2014 03:39:53 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.redhat.com", Issuer "Red Hat IS CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id AD3F11FCAAC for ; Wed, 20 Aug 2014 03:39:50 +0000 (UTC) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7K3dm8Z030509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 19 Aug 2014 23:39:48 -0400 Received: from sifl.localnet (vpn-59-72.rdu2.redhat.com [10.10.59.72]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7K3dlpS031216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2014 23:39:48 -0400 Delivered-To: bind9-bugs@bugs.isc.org Subject: Re: BIND 9.10.1 beta with seccomp functionality User-Agent: KMail/4.13.3 (Linux/3.15.9-gentoo; KDE/4.13.3; x86_64; ; ) Return-Path: X-Original-To: bind9-bugs@bugs.isc.org Date: Tue, 19 Aug 2014 23:39:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.ams1.isc.org To: secure-development@redhat.com, Andrew Griffiths Content-Transfer-Encoding: 7Bit From: Paul Moore X-RT-Original-Encoding: us-ascii Content-Length: 681 On Tuesday, August 19, 2014 08:45:01 PM Andrew Griffiths wrote: > - applying seccomp rules to all running threads may be possible via > https://lkml.org/lkml/2014/7/10/538 .. but I would strongly > recommend that all privilege dropping / process restriction is performed > before creating threads, as it's the only portable to way to ensure that > there aren't threads running with higher privileges, or running > unrestricted. Just an FYI, as the seccomp filter thread sync functionality is still quite new, support does not yet exist in libseccomp. Support is planned, I just haven't added it yet. -- paul moore security and virtualization @ redhat