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

[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 you enable audio support at runtime a set of syscalls will be added to
> > the filter 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.
> 
> How come? I think it is safer than forcing an admin to re-compile everything
> (which just won't happen in an enterprise environment).

For starters, I don't believe that a random administrator understands the QEMU 
code and the potential impact of any changes to such a config file as well as 
the QEMU developers.

> ... If any configuration file only increases the strictness of a syscall, I
> don't see the danger of an admin shooting themselves in the foot. Allowing
> an admin to decrease security would be a problem, but they can do -sandbox
> off anyway.

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.

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