> 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
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
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
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
ermitted 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 wrote:
> > > > I'm starting to wo
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 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 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 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
> >
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
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
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,
> >>&
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
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
;
> 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
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
> >
ngs, but it may be worth doing a
new release in the meantime.
--
paul moore
security and virtualization @ redhat
_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
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
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
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 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
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
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
-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
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
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
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 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 ...
> >
> > ---
> >
> >
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
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
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
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
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
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 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
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
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
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 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 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
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
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.
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
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
#include
> #include "qemu/osdep.h"
>
> -int seccomp_start(void);
> +int seccomp_start(int list_type);
> +
> #endif
--
paul moore
security and virtualization @ redhat
available in the git repository 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
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
&
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:
&g
emu-devel
is not interested 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 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 creati
hings which require privileges
> seccomp is blocking, then libvirt should avoid 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
&
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
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d128ed0..09c5148 100644
> --- a/MAINTAINERS
&
f it makes more sense to the
QEMU devs you can always add me as a co-maintainer.
Regardless, I do plan on continuing to review/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
ull request?
>
> Paolo
Out of respect for the work 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 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
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
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 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
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
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
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
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 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
>
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 $1
On Thursday, July 18, 2013 10:31:46 PM Peter Maydell wrote:
> On 18 July 2013 21:05, Paul Moore wrote:
> > On Thursday, July 18, 2013 08:48:10 PM Peter Maydell wrote:
> >> On 18 July 2013 20:39, Paul Moore wrote:
> >> > On the plus side, I think libseccomp is v
On Thursday, July 18, 2013 08:48:10 PM Peter Maydell wrote:
> On 18 July 2013 20:39, Paul Moore 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
ave such a tool the moment - it's
hard enough generating correct filters with a nice architecture agnostic
manner :)
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
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 $1
Signed-off-by: Paul Moore
---
qemu-seccomp.c |3 ++-
1 file changed, 2
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
{ 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
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
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 -
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
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
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.
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
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
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
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 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
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 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
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 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
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
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 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
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 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 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
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
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
), 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(
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
> > &
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
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
cation was not requested, QEMU operates normally.
Signed-off-by: Paul Moore
--
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 u
1 - 100 of 140 matches
Mail list logo
