lkml.org 
[lkml]   [2015]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Linux Firmware Signing
From
Date
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]
\
 
 \ /
  Last update: 2015-09-02 20:01    [W:0.084 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site