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

[Paul Moore <pmoore@redhat.com>]

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.

-- 
paul moore
security and virtualization @ redhat