for the fix.
> Cc: Paul Moore
> Signed-off-by: Anthony Liguori
> ---
> os-posix.c |5 +
> vl.c |3 ---
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/os-posix.c b/os-posix.c
> index daf3d6f..79fa228 100644
> --- a/os-posi
ed and in Fedora 18
>
> https://bugzilla.redhat.com/show_bug.cgi?id=830992
What Daniel said. If you're asking about F17, I don't plan on adding
libseccomp to releases prior to F18.
--
paul moore
security and virtualization @ redhat
On Monday, June 18, 2012 09:31:03 AM Daniel P. Berrange wrote:
> On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
> > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
> > > I think allowing execve() would render seccomp pretty much useless.
> >
> >
On Monday, June 18, 2012 02:55:35 PM Daniel P. Berrange wrote:
> On Mon, Jun 18, 2012 at 09:52:44AM -0400, Paul Moore wrote:
> > On Monday, June 18, 2012 09:31:03 AM Daniel P. Berrange wrote:
> > > On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
> > > >
d also submit that
patch too? I think we would want the debugging patch #ifdef'd out in normal
use, but I think it might help the QEMU developers.
--
paul moore
security and virtualization @ redhat
On Wednesday, September 26, 2012 01:24:54 PM Eduardo Otubo wrote:
> On Wed, Sep 26, 2012 at 11:14:29AM -0400, Paul Moore wrote:
> > On Thursday, September 20, 2012 06:00:59 PM Eduardo Otubo wrote:
> > > Seccomp syscall whitelist updated after tests running qemu under
> > &
), 241 },
> +{ SCMP_SYS(fstatfs), 241 },
> +{ SCMP_SYS(epoll_create), 241 },
> +{ SCMP_SYS(epoll_ctl), 241 },
> +{ SCMP_SYS(epoll_wait), 241 },
> +{ SCMP_SYS(pipe), 241 },
> +{ SCMP_SYS(poll), 241 },
> +{ SCMP_SYS(rt_sigpending), 241 },
> +{ SCMP_SYS(
pproach should be easier to maintain and would result in less
overhead in the kernel's seccomp evaluator (the blacklist filter would be much
smaller than a second whitelist filter).
-Paul
--
paul moore
security and virtualization @ redhat
e the 'scmp_sys_resolver' tool installed on your system (libseccomp-
devel >= 2.1.0 on Fedora) you can then resolve the syscall number:
# scmp_sys_resolver 2
open
It is also worth mentioning that while scmp_sys_resolver resolves syscalls for
the native architecture by default, it can resolve for any of the
architectures that libseccomp supports, see the manpage for details
(currently: x86, x86_64, x32, and arm).
--
paul moore
security and virtualization @ redhat
On Friday, August 30, 2013 11:27:28 AM Eduardo Otubo wrote:
> On 08/29/2013 09:56 AM, Paul Moore wrote:
> > On Wednesday, August 28, 2013 10:04:32 PM Eduardo Otubo wrote:
> >> Now there's a second whitelist, right before the vcpu starts. The second
> >> whitel
itelist + blacklist.
> >
> > If this is acceptable though, then I wonder how we could go about adding
> > new syscalls to the blacklist in future QEMU releases without regressing
> > "-sandbox on,strict=on".
>
> Maybe a better approach is to provide support that
On Tuesday, September 03, 2013 05:07:53 PM Eduardo Otubo wrote:
> On 09/03/2013 03:21 PM, Paul Moore wrote:
> > On Tuesday, September 03, 2013 02:08:28 PM Corey Bryant wrote:
> >> On 09/03/2013 02:02 PM, Corey Bryant wrote:
> >>> On 08/30/2013 10:21 AM, Eduardo Otubo
On Wednesday, September 04, 2013 09:25:08 AM Eduardo Otubo wrote:
> This was causing Qemu process to hang when using -sandbox on.
>
> Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1004175
>
> Signed-off-by: Eduardo Otubo
Works for me.
Tested-by: Paul Moore
t 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.
--
paul moore
security and virtualization @ redhat
QEMU needs to call semctl() for correct operation. This particular
problem was identified on shutdown with the following commandline:
# qemu -sandbox on -monitor stdio \
-device intel-hda -device hda-duplex -vnc :0
Signed-off-by: Paul Moore
---
qemu-seccomp.c |3 ++-
1 file changed, 2
On Wednesday, July 24, 2013 03:02:23 PM Eduardo Otubo wrote:
> On 07/23/2013 10:57 AM, Paul Moore wrote:
> > On Monday, July 15, 2013 03:32:01 PM Paul Moore wrote:
> >> A previous commit, "seccomp: add the asynchronous I/O syscalls to the
> >> whitelist", ad
On Wednesday, July 24, 2013 03:01:57 PM Eduardo Otubo wrote:
> On 07/23/2013 10:57 AM, Paul Moore wrote:
> > On Thursday, July 18, 2013 09:57:03 AM Paul Moore wrote:
> >> It appears that even a very simple /etc/qemu-ifup configuration can
> >>
> >> requi
ts on the patchset seems to be dwindling, we're on the 14th revision
and it looks like most of the issues have been addressed - any hope on getting
this merged in the near future?
Thanks.
--
paul moore
virtualization @ redhat
On Thursday, January 12, 2012 11:59:54 AM Paul Moore wrote:
> On Wednesday, December 14, 2011 08:43:15 AM Stefan Berger wrote:
> > The following series of patches adds TPM (Trusted Platform Module)
> > support to Qemu. An emulator for the TIS (TPM Interface Spec) interface
&g
send the patch, but before I do I want to make sure the defaults are
set to whatever you find acceptable to merging and the second sentence above
has me a little confused; do you mean "... dislike _enabling_ a feature when a
user isn't asking for it."?
--
paul moore
security and virtualization @ redhat
to be honest, that requirement above seems just as silly to me, if not more
so. However, if making this behavior optional is what it takes to get the
patch accepted, so be it.
I'll start working on v4 of the patch tomorrow.
--
paul moore
security and virtualization @ redhat
On Tuesday, June 05, 2012 11:51:40 PM Alexander Graf wrote:
> On 05.06.2012, at 23:45, Paul Moore wrote:
> > On Tuesday, June 05, 2012 03:08:26 AM Alexander Graf wrote:
> >> Which gets me to a new idea. Why not exit(1) when we detect FIPS and a
> >> password is set?
On Wednesday, June 06, 2012 01:56:52 AM Alexander Graf wrote:
> On 06.06.2012, at 01:07, Anthony Liguori wrote:
> > On 06/06/2012 06:06 AM, Paul Moore wrote:
> >> On Tuesday, June 05, 2012 11:51:40 PM Alexander Graf wrote:
> >>> On 05.06.2012, at 23:45, Paul Moore wro
On Thursday, June 07, 2012 12:31:25 PM Alexander Graf wrote:
> On 07.06.2012, at 05:10, Anthony Liguori wrote:
> > On 06/07/2012 06:56 AM, Paul Moore wrote:
> >> On Wednesday, June 06, 2012 01:56:52 AM Alexander Graf wrote:
> >>> The other one (FIPS) is basically a
On Thursday, June 07, 2012 09:21:12 AM Paul Moore wrote:
> On Thursday, June 07, 2012 12:31:25 PM Alexander Graf wrote:
> > On 07.06.2012, at 05:10, Anthony Liguori wrote:
> > > On 06/07/2012 06:56 AM, Paul Moore wrote:
> > >> On Wednesday, June 06, 2012 01
message to stderr when the host system is
running in FIPS mode and a VNC password was specified on the commend line.
If the system is not running in FIPS mode, or is running in FIPS mode but
VNC password authentication was not requested, QEMU operates normally.
Signed-off-by: Paul Moore
--
Changelog
/Ubuntu and Fedora packaging is currently in
progress.
--
paul moore
security and virtualization @ redhat
On Thursday, June 14, 2012 02:59:06 PM Kees Cook wrote:
> On Wed, Jun 13, 2012 at 1:31 PM, Paul Moore wrote:
> > On Wednesday, June 13, 2012 04:20:20 PM Eduardo Otubo wrote:
> >> Hello all,
> >>
> >> This is the second effort to sandbox Qemu guests using Libs
s is more" applies.
Protecting against the abuse and misuse of execve() is something that is
better done with the host's access controls (traditional DAC, MAC via the LSM,
etc.).
--
paul moore
security and virtualization @ redhat
On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote:
> On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore wrote:
> > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
> >> I think allowing execve() would render seccomp pretty much useless.
> >
> > Not necessaril
I think it
might be helpful to reference the specification/version along with the page
number(s) just to remove any ambiguity.
> +static void tis_mem_writel_intern(void *opaque, target_phys_addr_t addr,
> + uint32_t val, bool hw_access)
--
paul moore
virtualization @ redhat
MIN(sizeof(s->buf),
> + s->loc[locty].r_buffer.size));
> +s->offset = s->loc[locty].r_offset;
Again ...
> +break;
> +default:
> +/* leak nothing */
> +memset(s->buf, 0x0, sizeof(s->buf));
Maybe?
> +break;
> +}
> +}
> +
> +s->be_driver->ops->save_volatile_data();
> +}
--
paul moore
virtualization @ redhat
On Sunday, September 11, 2011 12:45:05 PM Stefan Berger wrote:
> On 09/09/2011 05:13 PM, Paul Moore wrote:
> > On Wednesday, August 31, 2011 10:35:54 AM Stefan Berger wrote:
> >> Index: qemu-git/hw/tpm_tis.c
> >> ==
On Monday, September 12, 2011 07:37:25 PM Stefan Berger wrote:
> On 09/12/2011 05:16 PM, Paul Moore wrote:
> > On Sunday, September 11, 2011 12:45:05 PM Stefan Berger wrote:
> >> On 09/09/2011 05:13 PM, Paul Moore wrote:
> >>> On Wednesday, August 31, 2011 1
gt; are available in the git repository at:
>
> git://github.com/otubo/qemu.git seccomp
>
> Felix Geyer (1):
> seccomp: add timerfd_create and timerfd_settime to the whitelist
>
> Paul Moore (1):
> seccomp: add shmctl(), mlock(), and munlock() to the syscall whit
t; >
> > Peter filters on "for you to fetch changes up to" and your git didn't
> > include it. :)
>
> Yes. Also the commits don't have your signed-off-by:
> so I can't apply it.
Eduardo?
It is absurd that we have had two fixes held up this long for such silly
things.
--
paul moore
security and virtualization @ redhat
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: xu...@redhat.com
Signed-off-by: Paul Moore
---
qemu-seccomp.c |4 +++-
1 file changed
On Friday, January 03, 2014 09:24:57 PM Paolo Bonzini wrote:
> Il 03/01/2014 20:58, Paul Moore ha scritto:
> > The PulseAudio library attempts to do a mkdir(2) and fchmod(2) on
> > "/run/user//pulse" which is currently blocked by the syscall
> > filter; this patch a
le in the git repository at:
> > git://github.com/otubo/qemu.git seccomp
>
> It's been almost three weeks. What's holding this up?
Agreed, this is silly, especially for such a small and obvious fix.
--
paul moore
security and virtualization @ redhat
PulseAudio requires the use of shared memory so add shmget(), shmat(),
and shmdt() to the syscall whitelist.
Reported-by: xu...@redhat.com
Signed-off-by: Paul Moore
---
qemu-seccomp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qemu-seccomp.c b/qemu-seccomp.c
It turns out we need to add some additional syscalls to QEMU to make
PulseAudio happy. Two minor patches follow ...
---
Paul Moore (2):
seccomp: add mkdir() and fchmod() to the whitelist
seccomp: add some basic shared memory syscalls to the whitelist
qemu-seccomp.c |7
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: xu...@redhat.com
Signed-off-by: Paul Moore
---
qemu-seccomp.c |4 +++-
1 file changed
On Thursday, January 16, 2014 01:52:30 PM Eduardo Otubo wrote:
> On 01/15/2014 05:38 PM, Paul Moore wrote:
> > It turns out we need to add some additional syscalls to QEMU to make
> > PulseAudio happy. Two minor patches follow ...
> >
> > ---
> >
> >
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 de
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.
he parameters to
> restrict, like fd's the guest is allowed to read/write.
>
> Here's another thread where this was discussed:
> http://www.redhat.com/archives/libvir-list/2013-April/msg01501.html
Seems reasonable to me.
--
paul moore
security and virtualization @ redhat
intel-hda -device hda-duplex
Signed-off-by: Paul Moore
---
qemu-seccomp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qemu-seccomp.c b/qemu-seccomp.c
index caa926e..3db1e9b 100644
--- a/qemu-seccomp.c
+++ b/qemu-seccomp.c
@@ -225,7 +225,10 @@ static const struct
On Wednesday, February 26, 2014 10:25:01 AM Paul Moore wrote:
> 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
> t
ase the user's risk.
> > IMHO the test suite should probe to see if sandbox is working or not, and
> > just not use the "-sandbox on" arg if the host doesn't support it.
>
> But I think this could be done on virt-test as well :)
This would be ideal, but if you must have a fallback mechanism in QEMU proper,
make it separate from '-sandbox on' so that it doesn't break with the current
behavior and also makes it is obvious that the functionality is not
guaranteed, e.g. '-sandbox try' or similar.
--
paul moore
security and virtualization @ redhat
moment to verify this,
but on non-audit kernels the audit messages should be sent to syslog so you
*should* still be able to search for SECCOMP records regardless.
--
paul moore
security and virtualization @ redhat
On Wednesday, December 18, 2013 11:48:11 AM Corey Bryant wrote:
> This fixes a bug where we weren't exiting if seccomp_init() failed.
>
> Signed-off-by: Corey Bryant
> ---
> qemu-seccomp.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Paul Moore
> diff --g
ned_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=12087
comm="qemu-kvm" sig=31 syscall=62 compat=0 ip=0x7f7a1d2abc67 code=0x0
... if you are using syslog, feel free to use whatever tool you prefer, e.g.
grep, less, etc.
Once you have the syscall number, "syscall=62", in the audit message above,
you can use the 'scmp_sys_resolver' to resolve the number into a name:
# scmp_sys_resolver 62
kill
The 'scmp_sys_resolver' tool is part of the libseccomp-devel package on
Fedora/RHEL based systems, it may be packaged differently on other
distributions.
I'm always open to suggestions on how to improve the development/debugging
process, so if you have any ideas please let me know.
-Paul
--
paul moore
security and virtualization @ redhat
656): 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
Tested-by: CongLi
Signed-off-by: Paul Moore
---
qemu-seccomp.
but in theory it
> could work.
This is what I was discussing above. I think this is likely the next big
improvement.
--
paul moore
security and virtualization @ redhat
On Friday, November 22, 2013 11:39:31 AM Stefan Hajnoczi wrote:
> On Thu, Nov 21, 2013 at 10:48:58AM -0500, Paul Moore wrote:
> > I'm always open to suggestions on how to improve the development/debugging
> > process, so if you have any ideas please let me know.
>
> Th
On Friday, November 22, 2013 04:48:41 PM Stefan Hajnoczi wrote:
> On Fri, Nov 22, 2013 at 09:44:42AM -0500, Paul Moore wrote:
> > On Friday, November 22, 2013 11:39:31 AM Stefan Hajnoczi wrote:
> > > On Thu, Nov 21, 2013 at 10:48:58AM -0500, Paul Moore wrote:
> > > >
On Thursday, November 21, 2013 02:40:48 PM Eduardo Otubo wrote:
> On 11/21/2013 01:40 PM, Paul Moore wrote:
> > The kill() syscall is triggered with the following command:
> > # qemu -sandbox on -monitor stdio \
> >
> > -device intel-hda -device hda-
On Sunday, April 27, 2014 11:10:50 AM Paolo Bonzini wrote:
> Il 14/04/2014 16:47, Paul Moore ha scritto:
> >> > Yes. Also the commits don't have your signed-off-by:
> >> > so I can't apply it.
> >
> > Eduardo?
> >
> > It is absur
#include
> #include "qemu/osdep.h"
>
> -int seccomp_start(void);
> +int seccomp_start(int list_type);
> +
> #endif
--
paul moore
security and virtualization @ redhat
t; switch (list_type) {
> case WHITELIST:
> @@ -285,7 +285,7 @@ int seccomp_start(int list_type)
>
> rc = seccomp_load(ctx);
>
> - seccomp_return:
> +seccomp_return:
> if (ctx)
> seccomp_release(ctx);
> return rc;
Any particular reason these changes weren't folded into patch 1/3?
--
paul moore
security and virtualization @ redhat
On Wednesday, March 05, 2014 11:53:58 AM Eduardo Otubo wrote:
> On 03/03/2014 05:41 PM, Paul Moore wrote:
> > On Wednesday, February 26, 2014 10:25:01 AM Paul Moore wrote:
> >> Additional testing reveals that PulseAudio requires shmctl() and the
> >> mlock()/munlock
-off-by: Paul Moore
---
qemu-seccomp.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/qemu-seccomp.c b/qemu-seccomp.c
index caa926e..86210a4 100644
--- a/qemu-seccomp.c
+++ b/qemu-seccomp.c
@@ -225,7 +225,8 @@ static const struct QemuSeccompSyscall seccomp_whitelist
n happy to discuss how libseccomp handles the different
architectures, but that's probably a bit off-topic for this thread.
--
paul moore
security and virtualization @ redhat
On Wednesday, November 05, 2014 08:08:06 PM Peter Maydell wrote:
> On 5 November 2014 19:46, Paul Moore wrote:
> > On Wednesday, November 05, 2014 05:08:20 PM Peter Maydell wrote:
> >> On 5 November 2014 16:47, Eduardo Otubo wrote:
> >> > Right now seccomp is break
_config --cflags libseccomp`"
> +seccomp="yes"
> +else
> +if test "$seccomp" = "yes"; then
> + feature_not_found "libseccomp" "Install libseccomp devel >=
> 2.1.0" +fi
> +seccomp="no"
> +fi
> fi
> fi
> ##
Also, note the current release of libseccomp is v2.1.1 which has a number of
bug fixes on top of v2.1.0.
--
paul moore
security and virtualization @ redhat
ngs, but it may be worth doing a
new release in the meantime.
--
paul moore
security and virtualization @ redhat
On Thursday, November 06, 2014 05:36:04 PM Eduardo Otubo wrote:
> On Thu, Nov 06, 2014 at 11:22:16AM -0500, Paul Moore wrote:
> > On Thursday, November 06, 2014 03:49:18 PM Eduardo Otubo wrote:
> > > Right now seccomp is breaking the compilation of Qemu on armv7l due
> >
;
> This patch also fixes the bug:
> https://bugs.launchpad.net/qemu/+bug/1363641
>
> Signed-off-by: Eduardo Otubo
> ---
> configure | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Thanks Eduardo, I'll let you know once I've cut a new release of libs
The "memory-backend-ram" QOM object utilizes the mbind(2) syscall to
set the policy for a memory range. Add the syscall to the seccomp
sandbox whitelist.
Signed-off-by: Paul Moore
---
qemu-seccomp.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/qemu-seccom
e libseccomp project can look at adding some
additional automated tests so these issues will be caught at build/packaging
time, further, I think the QEMU project can restore ARM/seccomp support in the
next release and look at its own testing procedures to understand why this
issue wasn't caught earlier as well.
--
paul moore
security @ redhat
rpmbuild/BUILD/qemu-2.3.0-rc2/rules.mak:57: recipe
> > for target 'qemu-seccomp.o' failed
> > [ 551s] make: *** [qemu-seccomp.o] Error 1
> >
> > Is this a problem with libseccomp 2.2.0 / master and needs to be fixed
> > in the library? Or do we need to #if
On Thursday, April 09, 2015 02:28:24 PM Andreas Färber wrote:
> Am 09.04.2015 um 11:10 schrieb Paul Moore:
> > On Thursday, April 09, 2015 10:21:52 AM Eduardo Otubo wrote:
> >> On Thu, Apr 09, 2015 at 05=01=31AM +0200, Andreas Färber wrote:
> >>> Hello,
> >>&
I've suggested this in the past but to my knowledge no has done any work in
this direction, including myself. Despite the lack of progress, I still think
this is a very worthwhile idea.
--
paul moore
security @ redhat
er whitelist, if you enable a network device a different set of syscalls
will be added to the filter, and so on.
I think having an admin specified filter, either via a command line or
configuration file, is a step in the wrong direction.
--
paul moore
security @ redhat
filter, not always more.
Also, while yes, allowing an admin to disable the sandbox via a command line
switch does disable the seccomp filter, it is obvious that such a step is
being taken.
> But if the dynamic sandbox is strict enough for each feature, it'd be great.
--
paul moore
security @ redhat
> syscall argument filter can be created for a syscall which is not in the
> built-in whitelist, otherwise it would throw an error saying that you cannot
> create an argument filter for a syscall that is not permitted.
I would argue you should never be able to add a syscall to the white
x27;s used by __builtin___clear_cache.
> And, from libseccomp's git history it appears that syscall is known
>
> commit a710a2d246bdc73ba77e3ff5624e790688cc51fd
> Author: Paul Moore
> Date: Wed May 6 12:05:45 2015 -0400
>
> arm: add some missing syscall
On Monday, June 29, 2015 09:50:17 AM Andrew Jones wrote:
> On Fri, Jun 26, 2015 at 04:26:22PM -0400, Paul Moore wrote:
> > Perhaps a stupid question, but you did verify that it is cacheflush that
> > is causing the problem? The seccomp filter code will emit a message to
> >
On Monday, June 29, 2015 07:47:29 PM Andrew Jones wrote:
> On Mon, Jun 29, 2015 at 10:53:14AM -0400, Paul Moore wrote:
> > On Monday, June 29, 2015 09:50:17 AM Andrew Jones wrote:
> > > On Fri, Jun 26, 2015 at 04:26:22PM -0400, Paul Moore wrote:
> > > > Perhaps
On Tuesday, June 30, 2015 10:39:34 AM Andrew Jones wrote:
> On Mon, Jun 29, 2015 at 04:24:55PM -0400, Paul Moore wrote:
> > Hmm, so either the kernel is screwing up with the seccomp filter for this
> > particular syscall (unlikely) or libseccomp is screwing up the filter
> >
On Tuesday, June 30, 2015 06:07:40 PM Peter Maydell wrote:
> On 30 June 2015 at 18:01, Paul Moore wrote:
> > I'm starting to wonder if the 32-bit ARM build system didn't have
> > __NR_cacheflush defined in the system headers; that might explain some of
> > the
On Wednesday, July 01, 2015 02:07:49 PM Andrew Jones wrote:
> On Tue, Jun 30, 2015 at 01:18:49PM -0400, Paul Moore wrote:
> > On Tuesday, June 30, 2015 06:07:40 PM Peter Maydell wrote:
> > > On 30 June 2015 at 18:01, Paul Moore wrote:
> > > > I'm starting to wo
ew syscalls to the list: readlink, rt_sigpending, and
> rt_sigtimedwait
>
> Reported-by: Paul Moore
> Signed-off-by: Eduardo Otubo
> ---
> qemu-seccomp.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
I had an opportunity to test this patchset on a F17
On Friday, November 02, 2012 09:48:55 AM Corey Bryant wrote:
> On 11/01/2012 05:43 PM, Paul Moore wrote:
> > On Tuesday, October 23, 2012 03:55:29 AM Eduardo Otubo wrote:
> >> According to the bug 855162[0] - there's the need of adding new syscalls
> >> to the
On Friday, November 02, 2012 12:29:37 AM Eduardo Otubo wrote:
> On Thu, Nov 01, 2012 at 05:43:03PM -0400, Paul Moore wrote:
> > On Tuesday, October 23, 2012 03:55:29 AM Eduardo Otubo wrote:
> > > According to the bug 855162[0] - there's the need of adding new syscalls
>
On Friday, November 02, 2012 10:10:02 AM Paul Moore wrote:
> On Friday, November 02, 2012 09:48:55 AM Corey Bryant wrote:
> > On 11/01/2012 05:43 PM, Paul Moore wrote:
> > > On Tuesday, October 23, 2012 03:55:29 AM Eduardo Otubo wrote:
> > >> According to the bug 8
On Friday, November 02, 2012 10:43:41 AM Corey Bryant wrote:
> On 11/02/2012 10:38 AM, Paul Moore wrote:
> > On Friday, November 02, 2012 10:10:02 AM Paul Moore wrote:
> >> On Friday, November 02, 2012 09:48:55 AM Corey Bryant wrote:
> >>> On 11/01/2012 05:43 P
rent problems. I might suggest an initial, fairly permissive
whitelist followed by a follow-on blacklist if you want to disable certain
syscalls.
--
paul moore
security and virtualization @ redhat
On Friday, November 02, 2012 06:00:29 PM Corey Bryant wrote:
> On 11/02/2012 05:29 PM, Paul Moore wrote:
> > On Tuesday, October 23, 2012 03:55:31 AM Eduardo Otubo wrote:
> >> This patch includes a second whitelist right before the main loop. It's
> >> a small
On Monday, November 05, 2012 09:39:46 AM Corey Bryant wrote:
> On 11/02/2012 06:14 PM, Paul Moore wrote:
> > On Friday, November 02, 2012 06:00:29 PM Corey Bryant wrote:
> >> On 11/02/2012 05:29 PM, Paul Moore wrote:
> >>> On Tuesday, October 23, 2012 03:55:31 AM Ed
ing in the US),
I'm not sure how much progress I'll be able to make for the remainder of this
week. Sorry about that.
If you have any further questions about how, or what, I'm testing, just ask.
--
paul moore
security and virtualization @ redhat
On Monday, November 26, 2012 11:41:06 AM Corey Bryant wrote:
> On 11/21/2012 10:24 AM, Paul Moore wrote:
> > On Wednesday, November 21, 2012 11:20:44 AM Eduardo Otubo wrote:
> >> Hello folks,
> >>
> >> Does anyone had a chance to take a look at this? We woul
On Monday, November 26, 2012 02:59:21 PM Corey Bryant wrote:
> On 11/26/2012 12:08 PM, Paul Moore wrote:
> > On Monday, November 26, 2012 11:41:06 AM Corey Bryant wrote:
> >> On 11/21/2012 10:24 AM, Paul Moore wrote:
> >>> On Wednesday, November 21, 2012 1
On Monday, November 26, 2012 03:41:00 PM Paul Moore wrote:
> On Monday, November 26, 2012 02:59:21 PM Corey Bryant wrote:
> > On 11/26/2012 12:08 PM, Paul Moore wrote:
> > > On Monday, November 26, 2012 11:41:06 AM Corey Bryant wrote:
> > >> On 11/21/2012 10:24 AM
dora version wasn't logging info messages.
>
> Nonetheless, we'll send new patches soon. It looks like the following
> were missing: epoll_create, epoll_wait, and epoll_ctl
Great, glad to hear my test system wasn't just being stubborn :)
I'll re-test as soon as I see
On Thursday, November 29, 2012 01:56:41 PM Eduardo Otubo wrote:
> 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
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
---
qemu-seccomp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qemu-seccomp.c b/qemu-seccomp.c
On Wednesday, May 29, 2013 04:30:01 PM Paul Moore wrote:
> 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
> ---
> qemu-seccomp.c |5 -
On Wednesday, July 10, 2013 10:02:55 PM Andreas Färber wrote:
> Am 10.07.2013 16:31, schrieb Paul Moore:
> > On Wednesday, May 29, 2013 04:30:01 PM Paul Moore wrote:
> >> In order to enable the asynchronous I/O functionality when using the
> >> seccomp sandbox we
{ SCMP_SYS(getgroups32), 241 },
> @@ -193,7 +181,6 @@ static const struct QemuSeccompSyscall
> seccomp_whitelist[] = { { SCMP_SYS(lstat64), 241 },
> { SCMP_SYS(sendfile64), 241 },
> { SCMP_SYS(ugetrlimit), 241 },
> -#endif
> { SCMP_SYS(alarm), 241 },
> { SCMP_SYS(rt_sigsuspend), 241 },
> { SCMP_SYS(rt_sigqueueinfo), 241 },
--
paul moore
security and virtualization @ redhat
1 - 100 of 140 matches
Mail list logo
