OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity
3052d95190
qemu-e2k/qemu-seccomp.c

266 lines
8.1 KiB
C
Raw Normal View History

Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
/*
* QEMU seccomp mode 2 support with libseccomp
*
* Copyright IBM, Corp. 2012
*
* Authors:
* Eduardo Otubo <eotubo@br.ibm.com>
*
* This work is licensed under the terms of the GNU GPL, version 2. See
* the COPYING file in the top-level directory.
*
* Contributions after 2012-01-13 are licensed under the terms of the
* GNU GPL, version 2 or (at your option) any later version.
*/
#include <stdio.h>
#include <seccomp.h>
softmmu: move include files to include/sysemu/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-17 18:20:04 +01:00
#include "sysemu/seccomp.h"
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
struct QemuSeccompSyscall {
int32_t num;
uint8_t priority;
};
static const struct QemuSeccompSyscall seccomp_whitelist[] = {
{ SCMP_SYS(timer_settime), 255 },
{ SCMP_SYS(timer_gettime), 254 },
{ SCMP_SYS(futex), 253 },
{ SCMP_SYS(select), 252 },
{ SCMP_SYS(recvfrom), 251 },
{ SCMP_SYS(sendto), 250 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(socketcall), 250 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(read), 249 },
seccomp: add additional asynchronous I/O syscalls A previous commit, "seccomp: add the asynchronous I/O syscalls to the whitelist", added several asynchronous I/O syscalls but left out the io_submit() and io_cancel() syscalls. This patch corrects this by adding the two missing asynchronous I/O syscalls. Signed-off-by: Paul Moore <pmoore@redhat.com> Reviewed-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Message-id: 20130715193201.943.4913.stgit@localhost Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-15 21:32:01 +02:00
{ SCMP_SYS(io_submit), 249 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(brk), 248 },
{ SCMP_SYS(clone), 247 },
{ SCMP_SYS(mmap), 247 },
{ SCMP_SYS(mprotect), 246 },
{ SCMP_SYS(execve), 245 },
{ SCMP_SYS(open), 245 },
{ SCMP_SYS(ioctl), 245 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(socket), 245 },
{ SCMP_SYS(setsockopt), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(recvmsg), 245 },
{ SCMP_SYS(sendmsg), 245 },
{ SCMP_SYS(accept), 245 },
{ SCMP_SYS(connect), 245 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(socketpair), 245 },
{ SCMP_SYS(bind), 245 },
{ SCMP_SYS(listen), 245 },
{ SCMP_SYS(semget), 245 },
{ SCMP_SYS(ipc), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(gettimeofday), 245 },
{ SCMP_SYS(readlink), 245 },
{ SCMP_SYS(access), 245 },
{ SCMP_SYS(prctl), 245 },
{ SCMP_SYS(signalfd), 245 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(getrlimit), 245 },
{ SCMP_SYS(set_tid_address), 245 },
{ SCMP_SYS(statfs), 245 },
{ SCMP_SYS(unlink), 245 },
{ SCMP_SYS(wait4), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(fcntl64), 245 },
{ SCMP_SYS(fstat64), 245 },
{ SCMP_SYS(stat64), 245 },
{ SCMP_SYS(getgid32), 245 },
{ SCMP_SYS(getegid32), 245 },
{ SCMP_SYS(getuid32), 245 },
{ SCMP_SYS(geteuid32), 245 },
{ SCMP_SYS(sigreturn), 245 },
{ SCMP_SYS(_newselect), 245 },
{ SCMP_SYS(_llseek), 245 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(mmap2), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(sigprocmask), 245 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(sched_getparam), 245 },
{ SCMP_SYS(sched_getscheduler), 245 },
{ SCMP_SYS(fstat), 245 },
{ SCMP_SYS(clock_getres), 245 },
{ SCMP_SYS(sched_get_priority_min), 245 },
{ SCMP_SYS(sched_get_priority_max), 245 },
{ SCMP_SYS(stat), 245 },
{ SCMP_SYS(uname), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(eventfd2), 245 },
seccomp: add the asynchronous I/O syscalls to the whitelist In order to enable the asynchronous I/O functionality when using the seccomp sandbox we need to add the associated syscalls to the whitelist. Signed-off-by: Paul Moore <pmoore@redhat.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Message-id: 20130529203001.20939.83322.stgit@localhost Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-05-29 22:30:01 +02:00
{ SCMP_SYS(io_getevents), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(dup), 245 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(dup2), 245 },
{ SCMP_SYS(dup3), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(gettid), 245 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(getgid), 245 },
{ SCMP_SYS(getegid), 245 },
{ SCMP_SYS(getuid), 245 },
{ SCMP_SYS(geteuid), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(timer_create), 245 },
seccomp: fine tuning whitelist by adding times() This was causing Qemu process to hang when using -sandbox on as discribed on RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1004175 Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Tested-by: Paul Moore <pmoore@redhat.com> Acked-by: Paul Moore <pmoore@redhat.com>
2013-09-24 19:50:44 +02:00
{ SCMP_SYS(times), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(exit), 245 },
{ SCMP_SYS(clock_gettime), 245 },
{ SCMP_SYS(time), 245 },
{ SCMP_SYS(restart_syscall), 245 },
{ SCMP_SYS(pwrite64), 245 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(nanosleep), 245 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(chown), 245 },
{ SCMP_SYS(openat), 245 },
{ SCMP_SYS(getdents), 245 },
{ SCMP_SYS(timer_delete), 245 },
{ SCMP_SYS(exit_group), 245 },
{ SCMP_SYS(rt_sigreturn), 245 },
{ SCMP_SYS(sync), 245 },
{ SCMP_SYS(pread64), 245 },
{ SCMP_SYS(madvise), 245 },
{ SCMP_SYS(set_robust_list), 245 },
{ SCMP_SYS(lseek), 245 },
{ SCMP_SYS(pselect6), 245 },
{ SCMP_SYS(fork), 245 },
{ SCMP_SYS(rt_sigprocmask), 245 },
{ SCMP_SYS(write), 244 },
{ SCMP_SYS(fcntl), 243 },
{ SCMP_SYS(tgkill), 242 },
seccomp: add kill() to the syscall whitelist The kill() syscall is triggered with the following command: # qemu -sandbox on -monitor stdio \ -device intel-hda -device hda-duplex -vnc :0 The resulting syslog/audit message: # ausearch -m SECCOMP ---- time->Wed Nov 20 09:52:08 2013 type=SECCOMP msg=audit(1384912328.482:6656): auid=0 uid=0 gid=0 ses=854 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=12087 comm="qemu-kvm" sig=31 syscall=62 compat=0 ip=0x7f7a1d2abc67 code=0x0 # scmp_sys_resolver 62 kill Reported-by: CongLi <coli@redhat.com> Tested-by: CongLi <coli@redhat.com> Signed-off-by: Paul Moore <pmoore@redhat.com> Acked-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
2013-11-21 16:40:15 +01:00
{ SCMP_SYS(kill), 242 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(rt_sigaction), 242 },
{ SCMP_SYS(pipe2), 242 },
{ SCMP_SYS(munmap), 242 },
{ SCMP_SYS(mremap), 242 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(fdatasync), 242 },
{ SCMP_SYS(close), 242 },
{ SCMP_SYS(rt_sigpending), 242 },
{ SCMP_SYS(rt_sigtimedwait), 242 },
{ SCMP_SYS(readv), 242 },
{ SCMP_SYS(writev), 242 },
{ SCMP_SYS(preadv), 242 },
{ SCMP_SYS(pwritev), 242 },
{ SCMP_SYS(setrlimit), 242 },
{ SCMP_SYS(ftruncate), 242 },
{ SCMP_SYS(lstat), 242 },
{ SCMP_SYS(pipe), 242 },
{ SCMP_SYS(umask), 242 },
{ SCMP_SYS(chdir), 242 },
{ SCMP_SYS(setitimer), 242 },
{ SCMP_SYS(setsid), 242 },
{ SCMP_SYS(poll), 242 },
{ SCMP_SYS(epoll_create), 242 },
{ SCMP_SYS(epoll_ctl), 242 },
{ SCMP_SYS(epoll_wait), 242 },
{ SCMP_SYS(waitpid), 242 },
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
{ SCMP_SYS(getsockname), 242 },
{ SCMP_SYS(getpeername), 242 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(accept4), 242 },
seccomp: add timerfd_create and timerfd_settime to the whitelist libusb calls timerfd_create() and timerfd_settime() when it's built with timerfd support. Command to reproduce: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0 Log messages: audit(1390730418.924:135): auid=4294967295 uid=121 gid=103 ses=4294967295 pid=5232 comm="qemu-system-x86" sig=31 syscall=283 compat=0 ip=0x7f2b0f4e96a7 code=0x0 audit(1390733100.580:142): auid=4294967295 uid=121 gid=103 ses=4294967295 pid=16909 comm="qemu-system-x86" sig=31 syscall=286 compat=0 ip=0x7f03513a06da code=0x0 Reading a few hundred MB from a USB drive on x86_64 shows this syscall distribution. Therefore the timerfd_settime priority is set to 242. calls syscall --------- ---------------- 5303600 write 2240554 read 2167030 ppoll 2134828 ioctl 704023 timerfd_settime 689105 poll 83122 futex 803 writev 476 rt_sigprocmask 287 recvmsg 178 brk Signed-off-by: Felix Geyer <debfx@fobos.de> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
2014-01-30 21:28:17 +01:00
{ SCMP_SYS(timerfd_settime), 242 },
seccomp: adding new syscalls (bugzilla 855162) According to the bug 855162[0] - there's the need of adding new syscalls to the whitelist when using Qemu with Libvirt. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162 Reported-by: Paul Moore <pmoore@redhat.com> Tested-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-11-29 16:56:41 +01:00
{ SCMP_SYS(newfstatat), 241 },
{ SCMP_SYS(shutdown), 241 },
{ SCMP_SYS(getsockopt), 241 },
{ SCMP_SYS(semop), 241 },
{ SCMP_SYS(semtimedop), 241 },
{ SCMP_SYS(epoll_ctl_old), 241 },
{ SCMP_SYS(epoll_wait_old), 241 },
{ SCMP_SYS(epoll_pwait), 241 },
{ SCMP_SYS(epoll_create1), 241 },
{ SCMP_SYS(ppoll), 241 },
{ SCMP_SYS(creat), 241 },
{ SCMP_SYS(link), 241 },
{ SCMP_SYS(getpid), 241 },
{ SCMP_SYS(getppid), 241 },
{ SCMP_SYS(getpgrp), 241 },
{ SCMP_SYS(getpgid), 241 },
{ SCMP_SYS(getsid), 241 },
{ SCMP_SYS(getdents64), 241 },
{ SCMP_SYS(getresuid), 241 },
{ SCMP_SYS(getresgid), 241 },
{ SCMP_SYS(getgroups), 241 },
{ SCMP_SYS(getresuid32), 241 },
{ SCMP_SYS(getresgid32), 241 },
{ SCMP_SYS(getgroups32), 241 },
{ SCMP_SYS(signal), 241 },
{ SCMP_SYS(sigaction), 241 },
{ SCMP_SYS(sigsuspend), 241 },
{ SCMP_SYS(sigpending), 241 },
{ SCMP_SYS(truncate64), 241 },
{ SCMP_SYS(ftruncate64), 241 },
{ SCMP_SYS(fchown32), 241 },
{ SCMP_SYS(chown32), 241 },
{ SCMP_SYS(lchown32), 241 },
{ SCMP_SYS(statfs64), 241 },
{ SCMP_SYS(fstatfs64), 241 },
{ SCMP_SYS(fstatat64), 241 },
{ SCMP_SYS(lstat64), 241 },
{ SCMP_SYS(sendfile64), 241 },
{ SCMP_SYS(ugetrlimit), 241 },
{ SCMP_SYS(alarm), 241 },
{ SCMP_SYS(rt_sigsuspend), 241 },
{ SCMP_SYS(rt_sigqueueinfo), 241 },
{ SCMP_SYS(rt_tgsigqueueinfo), 241 },
{ SCMP_SYS(sigaltstack), 241 },
{ SCMP_SYS(signalfd4), 241 },
{ SCMP_SYS(truncate), 241 },
{ SCMP_SYS(fchown), 241 },
{ SCMP_SYS(lchown), 241 },
{ SCMP_SYS(fchownat), 241 },
{ SCMP_SYS(fstatfs), 241 },
{ SCMP_SYS(getitimer), 241 },
{ SCMP_SYS(syncfs), 241 },
{ SCMP_SYS(fsync), 241 },
{ SCMP_SYS(fchdir), 241 },
{ SCMP_SYS(msync), 241 },
{ SCMP_SYS(sched_setparam), 241 },
{ SCMP_SYS(sched_setscheduler), 241 },
{ SCMP_SYS(sched_yield), 241 },
{ SCMP_SYS(sched_rr_get_interval), 241 },
{ SCMP_SYS(sched_setaffinity), 241 },
{ SCMP_SYS(sched_getaffinity), 241 },
{ SCMP_SYS(readahead), 241 },
{ SCMP_SYS(timer_getoverrun), 241 },
{ SCMP_SYS(unlinkat), 241 },
{ SCMP_SYS(readlinkat), 241 },
{ SCMP_SYS(faccessat), 241 },
{ SCMP_SYS(get_robust_list), 241 },
{ SCMP_SYS(splice), 241 },
{ SCMP_SYS(vmsplice), 241 },
{ SCMP_SYS(getcpu), 241 },
{ SCMP_SYS(sendmmsg), 241 },
{ SCMP_SYS(recvmmsg), 241 },
{ SCMP_SYS(prlimit64), 241 },
seccomp: add the asynchronous I/O syscalls to the whitelist In order to enable the asynchronous I/O functionality when using the seccomp sandbox we need to add the associated syscalls to the whitelist. Signed-off-by: Paul Moore <pmoore@redhat.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Message-id: 20130529203001.20939.83322.stgit@localhost Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-05-29 22:30:01 +02:00
{ SCMP_SYS(waitid), 241 },
seccomp: add additional asynchronous I/O syscalls A previous commit, "seccomp: add the asynchronous I/O syscalls to the whitelist", added several asynchronous I/O syscalls but left out the io_submit() and io_cancel() syscalls. This patch corrects this by adding the two missing asynchronous I/O syscalls. Signed-off-by: Paul Moore <pmoore@redhat.com> Reviewed-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Message-id: 20130715193201.943.4913.stgit@localhost Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-15 21:32:01 +02:00
{ SCMP_SYS(io_cancel), 241 },
seccomp: add the asynchronous I/O syscalls to the whitelist In order to enable the asynchronous I/O functionality when using the seccomp sandbox we need to add the associated syscalls to the whitelist. Signed-off-by: Paul Moore <pmoore@redhat.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Message-id: 20130529203001.20939.83322.stgit@localhost Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-05-29 22:30:01 +02:00
{ SCMP_SYS(io_setup), 241 },
seccomp: add arch_prctl() to the syscall whitelist It appears that even a very simple /etc/qemu-ifup configuration can require the arch_prctl() syscall, see the example below: #!/bin/sh /sbin/ifconfig $1 0.0.0.0 up /usr/sbin/brctl addif <switch> $1 Signed-off-by: Paul Moore <pmoore@redhat.com> Reviewed-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Message-id: 20130718135703.8247.19213.stgit@localhost Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-18 15:57:03 +02:00
{ SCMP_SYS(io_destroy), 241 },
seccomp: add mkdir() and fchmod() to the whitelist The PulseAudio library attempts to do a mkdir(2) and fchmod(2) on "/run/user/<UID>/pulse" which is currently blocked by the syscall filter; this patch adds the two missing syscalls to the whitelist. You can reproduce this problem with the following command: # qemu -monitor stdio -device intel-hda -device hda-duplex If watched under strace the following syscalls are shown: mkdir("/run/user/0/pulse", 0700) fchmod(11, 0700) [NOTE: 11 is the fd for /run/user/0/pulse] Reported-by: xuhan@redhat.com Signed-off-by: Paul Moore <pmoore@redhat.com>
2014-01-15 20:38:51 +01:00
{ SCMP_SYS(arch_prctl), 240 },
{ SCMP_SYS(mkdir), 240 },
seccomp: add some basic shared memory syscalls to the whitelist PulseAudio requires the use of shared memory so add shmget(), shmat(), and shmdt() to the syscall whitelist. Reported-by: xuhan@redhat.com Signed-off-by: Paul Moore <pmoore@redhat.com>
2014-01-15 20:38:58 +01:00
{ SCMP_SYS(fchmod), 240 },
{ SCMP_SYS(shmget), 240 },
{ SCMP_SYS(shmat), 240 },
seccomp: add timerfd_create and timerfd_settime to the whitelist libusb calls timerfd_create() and timerfd_settime() when it's built with timerfd support. Command to reproduce: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0 Log messages: audit(1390730418.924:135): auid=4294967295 uid=121 gid=103 ses=4294967295 pid=5232 comm="qemu-system-x86" sig=31 syscall=283 compat=0 ip=0x7f2b0f4e96a7 code=0x0 audit(1390733100.580:142): auid=4294967295 uid=121 gid=103 ses=4294967295 pid=16909 comm="qemu-system-x86" sig=31 syscall=286 compat=0 ip=0x7f03513a06da code=0x0 Reading a few hundred MB from a USB drive on x86_64 shows this syscall distribution. Therefore the timerfd_settime priority is set to 242. calls syscall --------- ---------------- 5303600 write 2240554 read 2167030 ppoll 2134828 ioctl 704023 timerfd_settime 689105 poll 83122 futex 803 writev 476 rt_sigprocmask 287 recvmsg 178 brk Signed-off-by: Felix Geyer <debfx@fobos.de> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
2014-01-30 21:28:17 +01:00
{ SCMP_SYS(shmdt), 240 },
seccomp: add shmctl(), mlock(), and munlock() to the syscall whitelist Additional testing reveals that PulseAudio requires shmctl() and the mlock()/munlock() syscalls on some systems/configurations. As before, on systems that do require these syscalls, the problem can be seen with the following command line: # qemu -monitor stdio -sandbox on \ -device intel-hda -device hda-duplex Signed-off-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
2014-02-26 16:25:01 +01:00
{ SCMP_SYS(timerfd_create), 240 },
{ SCMP_SYS(shmctl), 240 },
{ SCMP_SYS(mlock), 240 },
{ SCMP_SYS(munlock), 240 }
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
};
int seccomp_start(void)
{
int rc = 0;
unsigned int i = 0;
scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_KILL);
if (ctx == NULL) {
seccomp: exit if seccomp_init() fails This fixes a bug where we weren't exiting if seccomp_init() failed. Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Acked-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Acked-by: Paul Moore <pmoore@redhat.com>
2013-12-18 17:48:11 +01:00
rc = -1;
Adding qemu-seccomp.[ch] (v8) Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1: - I added a syscall struct using priority levels as described in the libseccomp man page. The priority numbers are based to the frequency they appear in a sample strace from a regular qemu guest run under libvirt. Libseccomp generates linear BPF code to filter system calls, those rules are read one after another. The priority system places the most common rules first in order to reduce the overhead when processing them. v1 -> v2: - Fixed some style issues - Removed code from vl.c and created qemu-seccomp.[ch] - Now using ARRAY_SIZE macro - Added more syscalls without priority/frequency set yet v2 -> v3: - Adding copyright and license information - Replacing seccomp_whitelist_count just by ARRAY_SIZE - Adding header protection to qemu-seccomp.h - Moving QemuSeccompSyscall definition to qemu-seccomp.c - Negative return from seccomp_start is fatal now. - Adding open() and execve() to the whitelis v3 -> v4: - Tests revealed a bigger set of syscalls. - seccomp_start() now has an argument to set the mode according to the configure option trap or kill. v4 -> v5: - Tests on x86_64 required a new specific set of system calls. - libseccomp release 1.0.0: part of the API have changed in this last release, had to adapt to the new function signatures.
2012-08-14 23:44:06 +02:00
goto seccomp_return;
}
for (i = 0; i < ARRAY_SIZE(seccomp_whitelist); i++) {
rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, seccomp_whitelist[i].num, 0);
if (rc < 0) {
goto seccomp_return;
}
rc = seccomp_syscall_priority(ctx, seccomp_whitelist[i].num,
seccomp_whitelist[i].priority);
if (rc < 0) {
goto seccomp_return;
}
}
rc = seccomp_load(ctx);
seccomp_return:
seccomp_release(ctx);
return rc;
}
Reference in New Issue Copy Permalink