Messages in this thread | | | Subject | Re: Linux Firmware Signing | From | Austin S Hemmelgarn <> | Date | Wed, 2 Sep 2015 13:36:25 -0400 |
| |
On 2015-09-02 12:45, Mimi Zohar wrote: > On Wed, 2015-09-02 at 08:28 -0700, Kees Cook wrote: >> On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote: >>> 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@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. >>> >>> What do you mean by "measured"? Who is doing the measurement? Could >>> someone detect a change in measurement? >> >> I meant from the perspective of IMA. The binary would have already >> been evaluated when it executed, and it's what's installing the >> seccomp filter. And since seccomp filters can only reduce privilege, >> it seems like they're not worth getting processed by IMA. But I might >> not understand the requirements! :) > > So because we trust the binary, we can trust the resulting output that > is loaded into the kernel. That assumes the trusted binary appraises > it's input, right? We're relying on seccomp filters to reduce > privileges properly. This isn't any different than trusting any other > policies consumed by the kernel. > Except many binaries that use seccomp (at least most of the ones that I've seen) don't change the filter based on input, but have it hard-coded into the binary and only offer to turn it on or off based on user input.
[unhandled content-type:application/pkcs7-signature] | |