qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eduardo Otubo
Subject: Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox
Date: Tue, 29 Sep 2015 17:38:07 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

(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 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 don't actually need it, or it's a bug and should be
> fixed. So all the config would do is add argument filters to syscalls which
> are already whitelisted. The alternative would be that the syscalls are given
> no further argument filtering. The config could only make the filteres more
> restrictive, never less.

By its concept, adding exception to the whitelist always makes it less
restrictive by definition, but I got your point. Another point here,
though, is that whitelisting syscall is not as common as you think it
is. I've been maintaining this sub-system for more than an year now and
I had to review/commit/push very few times.

Seccomp sandboxing is enabled by default on virt-test, so whoever is
using that framework is also testing their workload against the current
syscall whitelist. If no one has hit any problem so far, it means the
whitelist is in good shape for usual workloads and configurations.

I'm not particularly against any improvement like configuration files or
more command line args, but I'm concerned about the security itself. If
some guest can scape to the host, it's gonna be much easier to whitelist
syscalls for the next guests, changing the command line is a little too
obvious -- paranoid example, I know.

If you want to write an RFC with your idea, you're more than welcome. We
could move on this discussion and perhaps come up with a nice solution.

Regards,

> 
> Perhaps there could be a #define somewhere that toggles whether or not a
> 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.

-- 
Eduardo Otubo
ProfitBricks GmbH

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]