Re: Linux Firmware Signing

[Kees Cook]

On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
>> > > eBPF/seccomp
>
> OK I knew nothing about this but I just looked into it, here are my notes:
>
>   * old BPF - how far do we want to go? This goes so far as to parsing
>     user passed void __user *arg data through ioctls which typically
>     gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
>
>   * eBPF:
>                              seccomp() & prctl_set_seccomp()
>                                         |
>                                         V
>                              do_seccomp()
>                                         |
>                                         V
>                              seccomp_set_mode_filter()
>                                         |
>                                         V
>                              seccomp_prepare_user_filter()
>                                         |
>                                         V
>         bpf_prog_create_from_user() (seccomp) \
>         bpf_prog_create()                      > bpf_prepare_filter()
>         sk_attach_filter()                    /
>
>     All approaches come from user passed data, nothing fd based.
>
>     For both old BPF and eBPF then:
>
>     If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
>     Paul had mentioned up could be used to vet for passed filters, or
>     a new interface to enable fd based filters. This really would limit
>     the dynamic nature of these features though.
>
>     eBPF / secccomp would not be the only place in the kernel that would have
>     issues with user passed data, we have tons of places the same applies so
>     implicating the old BPF / eBPF / seccomp approaches can easily implicate
>     many other areas of the kernel, that's pretty huge but from the looks of
>     it below you seem to enable that to be a possibility for us to consider.

At the time (LSS 2014?) I argued that seccomp policies come from
binaries, which are already being measured. And that policies only
further restrict a process, so there seems to be to be little risk in
continuing to leave them unmeasured.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/