From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXbON-00070f-N3 for qemu-devel@nongnu.org; Wed, 01 May 2013 14:04:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXbOM-0003yG-9G for qemu-devel@nongnu.org; Wed, 01 May 2013 14:04:35 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:35439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXbOM-0003yA-4Y for qemu-devel@nongnu.org; Wed, 01 May 2013 14:04:34 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 1 May 2013 14:04:33 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 314C9C90049 for ; Wed, 1 May 2013 14:04:29 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r41I4TxC39387272 for ; Wed, 1 May 2013 14:04:29 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r41I4S9h018551 for ; Wed, 1 May 2013 14:04:29 -0400 Message-ID: <5181592B.4020301@linux.vnet.ibm.com> Date: Wed, 01 May 2013 14:04:27 -0400 From: Corey Bryant MIME-Version: 1.0 References: <517AC9E5.3050204@linux.vnet.ibm.com> <7515044.dYPbKXmJQB@sifl> <517EEB8A.7040700@linux.vnet.ibm.com> <3720772.nm306DgS3l@sifl> <51815017.50909@linux.vnet.ibm.com> In-Reply-To: <51815017.50909@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo Cc: Paul Moore , Paolo Bonzini , qemu-devel@nongnu.org, Eric Paris On 05/01/2013 01:25 PM, Eduardo Otubo wrote: > > > On 04/30/2013 12:24 PM, Paul Moore wrote: >> On Monday, April 29, 2013 05:52:10 PM Corey Bryant wrote: >>> On 04/26/2013 05:07 PM, Paul Moore wrote: >>>> [snip] >>>> >>>>>> 3. Debugging and/or learning mode - third party libraries still >>>>>> have the >>>>>> problem of interfering in the Qemu's signal mask. According to some >>>>>> previous discussions, perhaps patch all external libraries that >>>>>> mass up >>>>>> with this mask (spice, for example) is a way to solve it. But not >>>>>> sure >>>>>> if it worth the time spent. Would like to hear you guys. >>>> >>>> I think patching all the libraries is a losing battle, I think we >>>> need to >>>> pursue alternate debugging techniques. >>> >>> I agree. It would be nice to have some sort of learning mode that >>> reported all denied syscalls on a single run, but signal handlers >>> doesn't seem like the right way. Maybe we could improve on this >>> approach, since it never gained traction: >>> https://lkml.org/lkml/2013/1/7/313 >>> >>> At least we can get a single denied syscall at a time today via the >>> audit log that the kernel issues. Eduardo, you may want to see if >>> there's a good place to document that for QEMU so that people know where >>> to look. >> >> Lately I've been using the fact that the seccomp BPF filter result >> generates >> an audit log; it either dumps to syslog or the audit log (depending on >> your >> configuration) and seems to accomplish most of what we wanted with >> SECCOMP_RET_INFO. >> >> I'm always open to new/better ideas, but this has been working >> reasonably well >> for me for the past few months. > > I think this feature would fits well on Qemu if we could have a "normal" > signal handling. But external libraries interfere a lot on this matter. > > Paolo, am I the first one to complain about signal handling on Qemu > (being interfered by other libraries)? I believe this may cause some > trouble in other parts of the project as well. Wouldn't be this a good > time to, perhaps, just think about a signal handling refactoring? > You don't need signal handling to use what Paul was talking about above. I think that should be enough for -sandbox purposes, but perhaps you could document it somewhere for QEMU. -- Regards, Corey Bryant