"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
"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?
(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
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
> (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
> 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
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
> 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
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
> 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
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
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
>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
> 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
14 matches
Mail list logo