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 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.
If the syscall, without arguments, is already added to the whitelist then adding a new libseccomp rule to allow that same syscall with specific arguments will have no effect since a broader rule already exists in the filter. > The alternative would be that the syscalls are given no further argument > filtering. The config could only make the filteres more restrictive, never > less. I still don't see how this is the case, but it probably isn't worth arguing any further without some patches. > 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. I would argue you should never be able to add a syscall to the whitelist via a config file and/or command line option, but that is my opinion. -- paul moore security @ redhat
