Re: [Qemu-devel] [PATCH] seccomp: adding a second whitelist

[Paul Moore]

On Friday, August 30, 2013 05:23:45 PM Stefan Hajnoczi wrote:
> On Fri, Aug 30, 2013 at 4:21 PM, Eduardo Otubo <address@hidden> 
wrote:
> > On 08/29/2013 05:34 AM, Stefan Hajnoczi wrote:
> >> On Wed, Aug 28, 2013 at 10:04:32PM -0300, Eduardo Otubo wrote:
> >>> Now there's a second whitelist, right before the vcpu starts. The second
> >>> whitelist is the same as the first one, except for exec() and select().
> >> 
> >> -netdev tap,downscript=/path/to/script requires exec() in the QEMU
> >> shutdown code path.  Will this work with seccomp?
> > 
> > I actually don't know, but I'll test that as well. Can you run a test with
> > this patch and -netdev? I mean, if you're pointing that out you might have
> > a scenario already setup, right?
> 
> I'm not having much luck running qemu.git/master with CONFIG_SECCOMP
> on Fedora 19.  The GTK UI opens but I don't see the guest's display.
> 
> $ x86_64-softmmu/qemu-system-x86_64
> [...GTK UI opens but QEMU is hung...]
> 
> strace shows the process is hung somehow and ps says it's <defunct>
> although it never exited.
> 
> $ sudo cat /proc/5912/stack
> [<ffffffff81061fda>] do_exit+0x6ca/0xa20
> [<ffffffff810ef090>] __secure_computing+0xe0/0x240
> [<ffffffff8101d722>] syscall_trace_enter+0x172/0x230
> [<ffffffff816478c8>] tracesys+0x7e/0xe2
> [<ffffffffffffffff>] 0xffffffffffffffff
> 
> Okay, so seccomp killed the process.
> 
> $ sudo cat /proc/5912/syscall
> 29 0x0 0x1000 0x380 0x7fffbeb49380 0x0 0x0 0x7fffbeb495b8 0x7f6b72402657
> 
> $ git grep '\<29\>' arch/x86/include/generated/uapi/asm/unistd_64.h
> #define __NR_shmget 29
> 
> Now it needs syscall 30.  I guess the whitelist is only designed for a
> specific invocation that you are testing?

For future reference, it doesn't need to be that hard to identify when seccomp 
has killed a process.  If you're running audit go ahead and check the audit 
log:

 # ausearch -m SECCOMP
 ----
 time->Fri Aug 30 11:37:46 2013
 type=SECCOMP msg=audit(1377877066.414:64): auid=0 uid=0 gid=0 ses=1
 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3787
 comm="20-live-basic_d" sig=31 syscall=2 compat=0 ip=0x3a27ae6570 code=0x0

... and notice the 'syscall' field which in this case happens to be '2'.  If 
you have the 'scmp_sys_resolver' tool installed on your system (libseccomp-
devel >= 2.1.0 on Fedora) you can then resolve the syscall number:

 # scmp_sys_resolver 2
 open

It is also worth mentioning that while scmp_sys_resolver resolves syscalls for 
the native architecture by default, it can resolve for any of the 
architectures that libseccomp supports, see the manpage for details 
(currently: x86, x86_64, x32, and arm).

-- 
paul moore
security and virtualization @ redhat