netdev - Re: [net-next v3 1/2] bpf, seccomp: Add eBPF filter capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMp4zn-NNWT4mpmb_-5MV5urhj3KCzF=ZSoiHX54pLw3847Xrw@mail.gmail.com>
Date:   Mon, 26 Feb 2018 20:08:16 -0800
From:   Sargun Dhillon <sargun@...gun.me>
To:     Tycho Andersen <tycho@...ho.ws>
Cc:     netdev <netdev@...r.kernel.org>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Will Drewry <wad@...omium.org>,
        Kees Cook <keescook@...omium.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Andy Lutomirski <luto@...capital.net>
Subject: Re: [net-next v3 1/2] bpf, seccomp: Add eBPF filter capabilities

On Mon, Feb 26, 2018 at 7:57 PM, Tycho Andersen <tycho@...ho.ws> wrote:
> On Mon, Feb 26, 2018 at 07:49:48PM -0800, Sargun Dhillon wrote:
>> On Mon, Feb 26, 2018 at 4:54 PM, Tycho Andersen <tycho@...ho.ws> wrote:
>> > On Mon, Feb 26, 2018 at 07:27:05AM +0000, Sargun Dhillon wrote:
>> >> +config SECCOMP_FILTER_EXTENDED
>> >> +     bool "Extended BPF seccomp filters"
>> >> +     depends on SECCOMP_FILTER && BPF_SYSCALL
>> >> +     depends on !CHECKPOINT_RESTORE
>> >
>> > Why not just give -EINVAL or something in case one of these is
>> > requested, instead of making them incompatible at compile time?
>> >
>> > Tycho
>> There's already code to return -EMEDIUMTYPE if it's a non-classic, or
>> non-saved filter. Under the normal case, with CHECKPOINT_RESTORE
>> enabled, you should never be able to get that. I think it makes sense
>> to preserve this behaviour.
>
> Oh, right. So can't we just drop this, and the existing code will
> DTRT, i.e. give you -EMEDIUMTYPE because the new filters aren't
> supported, until they are?
>
> Tycho
My suggestion is we merge this as is, so we don't break checkpoint /
restore, and I will try to get the filter dumping patching in the same
development cycle as it comes at minimal risk. Otherwise, we risk
introducing a feature which could break checkpoint/restore, even in
unprivileged containers since anyone can load a BPF Seccomp filter.