[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: |
Mon, 29 Apr 2013 15:24:15 -0400 |
User-agent: |
KMail/4.10.2 (Linux/3.8.5-gentoo; KDE/4.10.2; x86_64; ; ) |
On Monday, April 29, 2013 03:39:57 PM Eduardo Otubo wrote:
> On 04/26/2013 06:07 PM, Paul Moore wrote:
> > On Friday, April 26, 2013 03:39:33 PM Eduardo Otubo wrote:
> > Also, looking a bit further ahead, it might be interesting to look at
> > removing some of the arch dependent stuff in qemu-seccomp.c. The latest
> > version of libseccomp should remove the need for many, if not all, of the
> > arch specific #ifdefs and the next version of libseccomp will add support
> > for x32 and ARM.
>
> Tell me more about this. You're saying I can remove the #ifdefs and keep
> the lines like "{ SCMP_SYS(getresuid32), 241 }, " or address these
> syscalls in another way?
Yes. If you are using libseccomp 2.x you shouldn't need any of the #ifdefs in
the seccomp_whitelist[] variable like there are at present. As long as you
aren't using the *_exact() versions of the libseccomp APIs, which QEMU is not,
the library will do the right thing for the current architecture: syscalls
that don't exist will be ignored, those that need translation, e.g. socket()
on x86, will be translated, and those that do exist normally will be handled
normally. Anything else I would consider a bug in libseccomp.
There is more to it if you are generating a seccomp filter to support multiple
simultaneous architectures, e.g. x86 and x86_64, but that doesn't really apply
with QEMU.
--
paul moore
security and virtualization @ redhat
Re: [Qemu-devel] [RFC] Continuous work on sandboxing, Corey Bryant, 2013/04/29