Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by default

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

On 12/04/2013 08:21 AM, Eduardo Otubo wrote:
>
>
> On 12/04/2013 07:39 AM, Stefan Hajnoczi wrote:
>> On Fri, Nov 22, 2013 at 11:00:24AM -0500, Paul Moore wrote:
>>>> Developers will only be happy with seccomp if it's easy and
>>>> rewarding to
>>>> support/debug.
>>>
>>> Agreed.
>>>
>>> As a developer, how do you feel about the audit/syslog based approach I
>>> mentioned earlier?
>>
>> I used the commands you posted (I think that's what you mean).  They
>> produce useful output.
>>
>> The problem is that without an error message on stderr or from the
>> shell, no one will think "QEMU process dead and hung == check seccomp"
>> immediately.  It's frustrating to deal with a "silent" failure.
>
> The process dies with a SIGKILL, and sig handling in Qemu is hard to
> implement due to dozen of external linked libraries that has their own
> signal masks and conflicts with seccomp. I've already tried this
> approach in the past (you can find in the list by searching for debug mode)

And just to be clear, the signal handling approach was only for debug 
purposes.

There are basically three ways to fail a syscall with seccomp:

SECCOMP_RET_KILL - kernel kills the task immediately without executing 
syscall
SECCOMP_RET_TRAP - kernel sends SIGSYS to the task without executing syscall
SECCOMP_RET_ERRNO - kernel returns an errno to the task wtihout 
executing syscall

You could issue a better error messages if you used TRAP or ERRNO, but 
giving control back to QEMU after (presumably) arbitrary code is being 
executed sort of defeats the purpose.

-- 
Regards,
Corey Bryant

>
> The optimal goal here is to use virt-test and audit log to eliminate
> these sorts of things.
>