Re: [Qemu-devel] [PATCH] Add syscalls for -runas and -chroot to the seccomp sandbox

[Eduardo Otubo <eduardo.otubo@profitbricks.com>]

[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]

On Fri, Oct 02, 2015 at 03=15=05PM +0100, Daniel P. Berrange wrote:
> On Fri, Oct 02, 2015 at 04:08:20PM +0200, Eduardo Otubo wrote:
> > On Fri, Oct 02, 2015 at 12=05=58PM +0200, Markus Armbruster wrote:
> > > "Daniel P. Berrange" <berrange@redhat.com> writes:
> > > 
> > > > On Thu, Oct 01, 2015 at 02:06:32PM +0200, Markus Armbruster wrote:
> > > >> "Namsun Ch'o" <namnamc@Safe-mail.net> writes:
> > > >> 
> > > >> > The seccomp sandbox doesn't whitelist setuid, setgid, or
> > > >> > setgroups, which are
> > > >> > needed for -runas to work. It also doesn't whitelist chroot, which is needed
> > > >> > for the -chroot option. Unfortunately, QEMU enables seccomp before it drops
> > > >> > privileges or chroots, so without these whitelisted, -runas and
> > > >> > -chroot cause
> > > >> > QEMU to be killed with -sandbox on. This patch adds those syscalls.
> > > >> 
> > > >> Should it enable seccomp a bit later?
> > > >
> > > > Yeah, I think it would be better to move the seccomp enablement later.
> > > 
> > > Let's do that then.
> > 
> > Where exactly you guys think we could call seccomp enablement? Right
> > it's called (almost) right before cpu_exec_init_all(), on vl.c:4013. I
> > guess it is as later as it could.
> 
> It depends on what you consider seccomp to be protecting against. I think
> its primary goal is to protect against exploit after a guest OS breakout,
> in which case it does not need to be enabled until the guest CPUs start
> executing, which IIUC, means immediately before main_loop().
> 
> 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.

Our intention since the beginning was to protect the host from the
illegal guest operations. But you do have an interesting point about
flaws on qemu itself. Perhaps this might be something I could work on to
improve (start a bigger whitelist and get it tighter before guest
launches).

-- 
Eduardo Otubo
ProfitBricks GmbH

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]