On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote: > 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. What do you mean by "measured"? Who is doing the measurement? Could someone detect a change in measurement? Mimi _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
