|
From: | Corey Bryant |
Subject: | Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by default |
Date: | Wed, 04 Dec 2013 09:46:39 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 |
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 syscallSECCOMP_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.
[Prev in Thread] | Current Thread | [Next in Thread] |