Re: Linux Firmware Signing

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3739 bytes --]

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.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]