> 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). 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. But if the dynamic sandbox is strict enough for each feature, it'd be great.
