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