I have no idea why the lines didn't wrap in my last post... Sorry about
that.
Signed-off-by: Namsun Ch'o
---
Changes so far:
v1
- Created argument filters for the madvise, shmget, and shmctl
syscalls.
v1 -> v2
- Added 5 new madvise flags which were present in the source code but
not in
the strace which I generated.
- Added IP_CREAT|0600 to shmget, whic
I think this patch should not be applied, because it completely defeats
the purpose of the sandbox. With these syscalls whitelisted, -runas
and
-chroot have absolutely no effect against an attacker, even with
-sandbox on.
Paolo
Adding chroot() and set*id() doesn't break the purpose of the sa
I guess this is addressed to Namsun's patches.
Namsun, can you rewrite the commit messages according to Peter's
suggestions and resend?
Sure. I used a longer commit message, and put the chatty stuff below the
---.
I posted it as a new top-level thread as a v3 patch.
> Drawback: complexity. If we decide to limit ourselves to the original
> threat model (rogue guest), and enter the sandbox only after setup, we
> can keep things simpler.
We could do both without much complexity. This looks simple enough to me:
rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_
> Our intention since the beginning was to protect the host from the
> illegal guest operations. But you do have an interesting point about
> flaws on qemu itself. Perhaps this might be something I could work on to
> improve (start a bigger whitelist and get it tighter before guest
> launches).
Th
> The pull request will be delayed a little bit due to some new patches
> incoming. Let's just set an agreement on how to approach regarding the
> "-runas and -chroot" patch and will prepare just a single batch for pull
> reuqest to Peter.
I also noticed that I had made that patch over the chroot
> If we intend seccomp to protect against flaws during QEMU setup, then having
> it earlier is neccessary. eg QEMU opening a corrupt qcow2 image which might
> exploit QEMU before the guest CPUs start.
> If the latter is the case, then we could start with a relaxed seccomp
> sandbox which included
-runas and -chroot cause
QEMU to be killed with -sandbox on. This patch adds those syscalls.
Signed-off-by: Namsun Ch'o
---
diff --git a/qemu-seccomp.c b/qemu-seccomp.c
index f9de0d3..5cb1809 100644
--- a/qemu-seccomp.c
+++ b/qemu-seccomp.c
@@ -237,7 +237,11 @@ static const struct Qem
> This looks good now.
> Thanks for your contribution.
> Acked-by: Eduardo Otubo
> ps.: I'll create a pull request with all changes made so far on Friday.
I was told on IRC to submit patches in smaller chunks, with a few new filters
at a time. Should I wait until it is merged, or should I go ah
> (I'm not sure what happens to your emails that all of them does not
> relate to the same thread/Message-ID, making a pain to follow through
> out the volume of email on the list, please pay attention to that)
I just click Reply All, I'm not sure how else I would do it. Are they somehow
being pos
> My understanding of the config file you proposed is that it would allow the
> configuration of a whitelist, so changes to the config very could result in
> *less* strict of a filter, not always more.
No. Any time an administrator wants a syscall that is not enabled in the
sandbox, they either do
> To be clear, I'm not suggesting "--enable-syscalls=foo,bar,...", what I'm
> suggesting is a decomposition of the current filter list into blocks of
> syscalls that are needed to enable specific functionality. For example, if
> you enable audio support at runtime a set of syscalls will be adde
> Actually on Mac OS X, /dev/cdrom always points to the optical drive.
> It is how QEMU is programmed.
Is this only for Mac? I must have missed that.
> Add a menu item to the Machine menu called "Use Real CDROM". It gives the
> user the ability to use a real CDROM with QEMU by simply selecting a menu
> item.
> NSASCIIStringEncoding];
> +qmp_change_blockdev(device, "/dev/cdrom", "raw", &err);
> +handleAnyDeviceErrors(err);
Not all syste
> 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.
Which is exactly why I think a configuration file would be the best option
instead of --enable-syscalls=fo
>Can you point out which exact use case breaks if you don't whitelist the
>below mentioned system calls' flags?
It happens whenever I do -runas with the sandbox enabled, or chroot with the
sandbox enabled.
sh# qemu-system-x86_64 -m 2048 -enable-kvm -chroot /var/empty -sandbox on \
> -cdrom /tmp/d
he comma on the last entry of the madvise_flags array.
- Removed one madvise flag (MADV_INVALID) which doesn't exist, apparently.
Signed-off-by: Namsun Ch'o
---
diff --git a/qemu-seccomp.c b/qemu-seccomp.c
index f9de0d3..a353ef9 100644
--- a/qemu-seccomp.c
+++ b/qemu-sec
> On Thursday, September 10, 2015 03:48:52 PM Daniel P. Berrange wrote:
> > On Wed, Sep 09, 2015 at 09:55:33PM -0400, namn...@safe-mail.net wrote:
> > > +
> > > +/* shmget */
> > > +rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(shmget), 2,
> > > +SCMP_A0(SCMP_CMP_EQ, IPC_PRIVA
19 matches
Mail list logo
