On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez <mcg...@suse.com> 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-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
