Re: [Qemu-devel] [RFC] Continuous work on sandboxing

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

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