[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Continuous work on sandboxing
From: |
Paul Moore |
Subject: |
Re: [Qemu-devel] [RFC] Continuous work on sandboxing |
Date: |
Tue, 30 Apr 2013 11:24:23 -0400 |
User-agent: |
KMail/4.10.2 (Linux/3.8.5-gentoo; KDE/4.10.2; x86_64; ; ) |
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