On Mon, Jan 23, 2017 at 12:20 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Sun, Jan 22, 2017 at 8:31 PM, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: >> On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: >>> restricting the types of sockets that can be created, then you do want >>> the filter to work across namespaces, but seccomp can do that too and >>> the current code doesn't handle netns correctly. >> >> are you saying that seccomp supports netns filtering? please show the proof. > > It can trivially restruct the types of sockets that are created by > filtering on socket(2) syscall parameters, at least on sane > architectures that don't use socketcall().
I think this is actually wrong -- the socket creation filter appears to be called only on inet sockets. Is there a good reason for that? > >> To summarize, I think the 'prog override is not allowed' flag would be >> ok feature to have and I wouldn't mind making it the default when no 'flag' >> field is passed to bpf syscall, but it's not acceptable to remove current >> 'prog override is allowed' behavior. >> So if you insist on changing the default, please implement the flag asap. >> Though from security point of view and ABI point of view there is absolutely >> no difference whether this flag is added today or a year later while >> the default is kept as-is. > > It's too late and I have too little time. I'll try to write a patch > to change the default to just deny attempts to override. Better > behavior can be added later. > > IMO your suggestions about priorities are overcomplicated. For your > instrumentation needs, I can imagine that a simple "make this hook not > run if a descendent has a hook" would do it. For everything else, run > them all in tree order (depending on filter type) and let the eBPF > code do whatever it wants to do. Is there any plan to address this? If not, I'll try to write that patch this weekend.