From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgg4f-0007RO-Al for qemu-devel@nongnu.org; Mon, 28 Sep 2015 17:35:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zgg4a-0002tr-2M for qemu-devel@nongnu.org; Mon, 28 Sep 2015 17:35:05 -0400 Received: from www.safe-mail.net ([212.29.227.230]:34660 helo=tapuz.safe-mail.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgg4Z-0002s2-RD for qemu-devel@nongnu.org; Mon, 28 Sep 2015 17:35:00 -0400 Date: Mon, 28 Sep 2015 17:34:53 -0400 From: "Namsun Ch'o" Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: pmoore@redhat.com Cc: qemu-devel@nongnu.org, eduardo.otubo@profitbricks.com > To be clear, I'm not suggesting "--enable-syscalls=foo,bar,...", what I'm > suggesting is a decomposition of the current filter list into blocks of > syscalls that are needed to enable specific functionality. For example, if > you enable audio support at runtime a set of syscalls will be added to the > filter whitelist, if you enable a network device a different set of syscalls > will be added to the filter, and so on. > > I think having an admin specified filter, either via a command line or > configuration file, is a step in the wrong direction. How come? I think it is safer than forcing an admin to re-compile everything (which just won't happen in an enterprise environment). If any configuration file only increases the strictness of a syscall, I don't see the danger of an admin shooting themselves in the foot. Allowing an admin to decrease security would be a problem, but they can do -sandbox off anyway. But if the dynamic sandbox is strict enough for each feature, it'd be great.