From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj12g-0001Q7-Vn for qemu-devel@nongnu.org; Mon, 05 Oct 2015 04:22:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zj12d-0001In-DC for qemu-devel@nongnu.org; Mon, 05 Oct 2015 04:22:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj12d-0001Ic-88 for qemu-devel@nongnu.org; Mon, 05 Oct 2015 04:22:39 -0400 Date: Mon, 5 Oct 2015 09:22:34 +0100 From: "Daniel P. Berrange" Message-ID: <20151005082234.GA19336@redhat.com> References: <878u7hao1x.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <878u7hao1x.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH] Add syscalls for -runas and -chroot tothe seccomp sandbox Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Namsun Ch'o , qemu-devel@nongnu.org On Mon, Oct 05, 2015 at 07:20:58AM +0200, Markus Armbruster wrote: > "Namsun Ch'o" writes: > > >> If we intend seccomp to protect against flaws during QEMU setup, then having > >> it earlier is neccessary. eg QEMU opening a corrupt qcow2 image which might > >> exploit QEMU before the guest CPUs start. > > > >> If the latter is the case, then we could start with a relaxed seccomp > >> sandbox which included the setuid/chroot features, and then switch to a > >> more restricted one which blocked them before main_loop() runs. > > > > That's not possible. Seccomp will not be enforced until seccomp_load(ctx) is > > called, after which no new changes to the filter can be made. > > That's a pity. > > As long as it's the case, we need to pick: either we protect against > rogue guests, or against rogue images. The original idea was the > former, and it still makes the most sense to me. Yep, protecting against rogue guests seems much more important. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|