Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1573443

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

Show all headers | View raw

On Mon, Jan 23, 2017 at 12:20 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Sun, Jan 22, 2017 at 8:31 PM, Alexei Starovoitov
> <alexei.starovoitov@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.

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: Potential issues (security and otherwise) with the current  cgroup-bpf API Andy Lutomirski <luto@amacapital.net> - 2017-02-03 22:10 +0100
  Re: Potential issues (security and otherwise) with the current  cgroup-bpf API Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2017-02-04 00:30 +0100
    Re: Potential issues (security and otherwise) with the current  cgroup-bpf API Andy Lutomirski <luto@kernel.org> - 2017-02-04 18:20 +0100

csiph-web