ter 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 whitelist via a
config file a
, 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
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
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
ted instead ?
> The latter is what I see gtk2 source code passing for mode.
It wouldn't match the rule as written above, if it doesn't match any other
configured rules it would hit the default filter action.
--
paul moore
security @ redhat
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 pmo...@redhat.com wrote:
I'm starting to wonder if the 32-bit ARM build
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
creation (more likely). I
On Tuesday, June 30, 2015 06:07:40 PM Peter Maydell wrote:
On 30 June 2015 at 18:01, Paul Moore pmo...@redhat.com 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 behavior. Could you check
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
syslog or the audit log
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 a stupid question, but you did verify
commit a710a2d246bdc73ba77e3ff5624e790688cc51fd
Author: Paul Moore pmo...@redhat.com
Date: Wed May 6 12:05:45 2015 -0400
arm: add some missing syscalls
Add the following syscalls to the ARM arch/ABI and update the syscall
validation script.
* breakpoint
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
in the library? Or do we need to #ifdef some syscalls in qemu-seccomp.c?
This should be already fixed in the library as mentioned by the
maintainer in this[0] thread. Adding Paul Moore in CC. There's also a
bug entry on launchpad[1] for that. I provided the patch (before the
pull reuqest
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 am seeing the following build failure
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 pmo...@redhat.com
---
qemu-seccomp.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/qemu
fixes the bug:
https://bugs.launchpad.net/qemu/+bug/1363641
Signed-off-by: Eduardo Otubo eduardo.ot...@profitbricks.com
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Thanks Eduardo, I'll let you know once I've cut a new release of libseccomp.
Acked-by: Paul Moore
, 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
, 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
to libsecomp current lack
-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 pmo...@redhat.com 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 breaking the compilation
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 pmo...@redhat.com
---
qemu-seccomp.c |3
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 absurd that we have had two fixes held up this long for such silly
things.
It's
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
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 whitelist
qemu-seccomp.c |7 ++-
1 files changed, 6
-off-by: Paul Moore pmo...@redhat.com
---
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
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() syscalls on some systems
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
the following
intel-hda -device hda-duplex
Signed-off-by: Paul Moore pmo...@redhat.com
---
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
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 ...
---
Paul Moore (2):
seccomp: add mkdir() and fchmod
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 pmo...@redhat.com
---
qemu-seccomp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qemu-seccomp.c b
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
-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 pmo...@redhat.com
---
qemu-seccomp.c |4 +++-
1 file changed, 3
-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 pmo...@redhat.com
---
qemu-seccomp.c |4 +++-
1 file changed, 3
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/UID/pulse which is currently blocked by the syscall
filter; this patch adds the two missing syscalls
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 cor...@linux.vnet.ibm.com
---
qemu-seccomp.c | 1 +
1 file changed, 1 insertion(+)
Acked-by: Paul Moore pmo...@redhat.com
diff
and independent subsystems
in the kernel.
Also, and I don't have a non-audit kernel built at the 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
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
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-duplex -vnc :0
The resulting syslog
.
--
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.
The failure mode is terrible:
Glad
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:
I'm always open to suggestions on how
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
): 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 c...@redhat.com
Tested-by: CongLi c...@redhat.com
Signed-off-by: Paul Moore pmo
--
paul moore
security and virtualization @ redhat
)
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
at:
git://github.com/otubo/qemu.git seccomp
Eduardo Otubo (1):
seccomp: fine tuning whitelist by adding times()
qemu-seccomp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Just a follow-up ping to see where things stand on this bugfix ...
--
paul moore
security
On Wednesday, September 04, 2013 10:11:10 AM Paul Moore wrote:
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
On Wednesday, September 18, 2013 04:59:10 PM Daniel P. Berrange wrote:
On Wed, Sep 18, 2013 at 11:53:09AM -0400, Paul Moore wrote:
On Wednesday, September 18, 2013 08:38:17 AM Daniel P. Berrange wrote:
Libvirt does not want to be in the business of creating seccomp syscall
filters
in, what about libvirt-lxc? What about all of the other
virtualization drivers supported by libvirt (granted, not all would be
candidates for syscall filtering, but you get the idea).
--
paul moore
security and virtualization @ redhat
On Wednesday, September 18, 2013 05:32:17 PM Daniel P. Berrange wrote:
On Wed, Sep 18, 2013 at 12:19:44PM -0400, Paul Moore wrote:
On Wednesday, September 18, 2013 04:59:10 PM Daniel P. Berrange wrote:
On Wed, Sep 18, 2013 at 11:53:09AM -0400, Paul Moore wrote:
On Wednesday, September 18
using them. eg by making
use of FD passing where appropriate to reduce privileges qemu needs.
I agree.
--
paul moore
security and virtualization @ redhat
On Wednesday, September 04, 2013 10:11:10 AM Paul Moore wrote:
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
that Eduardo has done, and is continuing to do,
with the QEMU seccomp filtering, I think Eduardo should be the one to take on
this role. If Eduardo declines I'll do ahead and submit a patch adding myself
to the MAINTAINERS file.
On 09/04/2013 11:11 AM, Paul Moore wrote:
On Wednesday
/test patches and I don't expect
that to change in the near future.
Please wait for Anthony's ack. I changed the subject and CCed him to
grab his attention.
Paolo
--
paul moore
security and virtualization @ redhat
to the MAINTAINERS
file so I can take care of the sandbox feature in Qemu.
MAINTAINERS |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
Acked-by: Paul Moore pmo...@redhat.com
diff --git a/MAINTAINERS b/MAINTAINERS
index d128ed0..09c5148 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
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 ot...@linux.vnet.ibm.com
Works for me.
Tested-by: Paul Moore pmo
this until I had some patches ready to post, but
I'm currently working on adding syscall filtering, via libseccomp, to libvirt.
I hope to get an initial RFC-quality patch out soon.
--
paul moore
security and virtualization @ redhat
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 wrote:
On 08/29/2013 05:34 AM, Stefan
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
whitelist is the same as the first one, except
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
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, added several asynchronous I/O syscalls but left out
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
require the arch_prctl() syscall, see the example below
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, 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
On Thursday, July 18, 2013 09:57:03 AM Paul Moore wrote:
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
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 pmo...@redhat.com
---
qemu-seccomp.c |3
is very close to being pretty much
feature complete (excluding new architectures that may pop up, at present we
are only x86, x86_64, x32, and ARM) so I'll be able to start turning some
effort towards better tools and patches for existing applications.
--
paul moore
security and virtualization
On Thursday, July 18, 2013 08:48:10 PM Peter Maydell wrote:
On 18 July 2013 20:39, Paul Moore pmo...@redhat.com wrote:
On the plus side, I think libseccomp is very close to being pretty much
feature complete (excluding new architectures that may pop up, at present
we are only x86, x86_64
On Thursday, July 18, 2013 10:31:46 PM Peter Maydell wrote:
On 18 July 2013 21:05, Paul Moore pmo...@redhat.com wrote:
On Thursday, July 18, 2013 08:48:10 PM Peter Maydell wrote:
On 18 July 2013 20:39, Paul Moore pmo...@redhat.com wrote:
On the plus side, I think libseccomp is very close
},
--
paul moore
security and virtualization @ redhat
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 pmo...@redhat.com
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 pmo...@redhat.com
---
qemu-seccomp.c |5 -
1 file
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 need to add the associated syscalls
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 pmo...@redhat.com
---
qemu-seccomp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qemu-seccomp.c b
this was discussed:
http://www.redhat.com/archives/libvir-list/2013-April/msg01501.html
Seems reasonable to me.
--
paul moore
security and virtualization @ redhat
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
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
all the libraries is a losing battle, I think we need to
pursue alternate debugging techniques.
--
paul moore
security and virtualization @ redhat
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 Moore pmo...@redhat.com
Signed
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 the patches.
--
paul moore
security
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 would like to get
this into the 1.3 release
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 11:20:44 AM Eduardo Otubo wrote:
Hello folks
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, Paul Moore wrote:
On Wednesday
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 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 Eduardo Otubo wrote:
This patch includes
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 whitelist whenn using Qemu with Libvirt
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
to the whitelist whenn using
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 855162[0] - there's the need of adding new
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 PM, Paul Moore wrote:
On Tuesday, October 23
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 smaller and more restricted whitelist, excluding
, rt_sigpending, and
rt_sigtimedwait
Reported-by: Paul Moore pmo...@redhat.com
Signed-off-by: Eduardo Otubo ot...@linux.vnet.ibm.com
---
qemu-seccomp.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
I had an opportunity to test this patchset on a F17 machine using QEMU
/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
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
libvirt ...
Hi Eduardo
(epoll_wait), 241 },
+{ SCMP_SYS(pipe), 241 },
+{ SCMP_SYS(poll), 241 },
+{ SCMP_SYS(rt_sigpending), 241 },
+{ SCMP_SYS(rt_sigtimedwait), 241 },
};
int seccomp_start(void)
--
paul moore
security and virtualization @ redhat
f16-test-1.xml
Description: XML document
.
Cc: Paul Moore pmo...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
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-posix.c
+++ b/os-posix.c
was not requested, QEMU operates normally.
Signed-off-by: Paul Moore pmo...@redhat.com
--
Changelog
* v5
- Added the '-enable-fips' command line option
* v4
- Removed the use of syslog
* v3
- Use fgetc() instead of fgets() in fips_enabled
- Only emit a syslog message if the caller tries to use VNC
On Friday, June 08, 2012 05:38:12 PM Paul Moore wrote:
FIPS 140-2 requires disabling certain ciphers, including DES, which is used
by VNC to obscure passwords when they are sent over the network. The
solution for FIPS users is to disable the use of VNC password auth when the
host system
1 - 100 of 139 matches
Mail list logo
