Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-10-01 Thread Markus Armbruster
"Namsun Ch'o" writes: >> (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

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-10-01 Thread Markus Armbruster
"Namsun Ch'o" writes: >> This message lacks In-Reply-To: and References: headers. Whatever you >> use to send e-mail seems grossly deficient. Perhaps it has some "don't >> be such an ass" configuration button, but I doubt it. > > I've switched providers. Is this one better?

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-30 Thread Eduardo Otubo
(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) On Mon, Sep 28, 2015 at 11=14=42PM -0400, Namsun Ch'o wrote: > > My understanding of the

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-30 Thread Paul Moore
On Monday, September 28, 2015 11:14:42 PM Namsun Ch'o wrote: > > 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

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-30 Thread Namsun Ch'o
> (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

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-28 Thread Namsun Ch'o
> 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

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-28 Thread Paul Moore
On Monday, September 28, 2015 05:34:53 PM Namsun Ch'o wrote: > > 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

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-28 Thread Namsun Ch'o
> 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

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-28 Thread Paul Moore
On Saturday, September 26, 2015 01:06:57 AM Namsun Ch'o wrote: > > 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

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-25 Thread Namsun Ch'o
> 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

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-25 Thread Paul Moore
On Friday, September 25, 2015 12:53:04 AM Namsun Ch'o wrote: > Another idea which would fit in with the security model is to have a dynamic > sandbox which enables syscalls and syscall filters based on what command > line or config parameters are passed to QEMU on its first start. I've suggested

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-24 Thread Eduardo Otubo
On Thu, Sep 10, 2015 at 08=54=28PM -0400, namn...@safe-mail.net wrote: > > The current intention of the seccomp filter in QEMU, is that /all/ existing > > QEMU features continue to work unchanged. So even if a flag is used in a > > seemingly uncommon code path, we still need to allow that in a

Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-24 Thread Namsun Ch'o
>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

[Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox

2015-09-10 Thread namnamc
> The current intention of the seccomp filter in QEMU, is that /all/ existing > QEMU features continue to work unchanged. So even if a flag is used in a > seemingly uncommon code path, we still need to allow that in a seccomp > filter. It already doesn't work very well, e.g. with -chroot, it fails