linux-kernel - Re: Linux Firmware Signing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 2 Sep 2015 13:36:25 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Kees Cook <keescook@...omium.org>
Cc:	"Luis R. Rodriguez" <mcgrof@...e.com>,
	David Woodhouse <dwmw2@...radead.org>,
	David Howells <dhowells@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	"Roberts, William C" <william.c.roberts@...el.com>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	"james.l.morris@...cle.com" <james.l.morris@...cle.com>,
	"serge@...lyn.com" <serge@...lyn.com>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Paul Moore <paul@...l-moore.com>,
	Eric Paris <eparis@...isplace.org>,
	SE Linux <selinux@...ho.nsa.gov>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	"Schaufler, Casey" <casey.schaufler@...el.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Peter Jones <pjones@...hat.com>, Takashi Iwai <tiwai@...e.de>,
	Ming Lei <ming.lei@...onical.com>, Joey Lee <jlee@...e.de>,
	Vojtěch Pavlík <vojtech@...e.com>,
	Kyle McMartin <kyle@...nel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Johannes Berg <johannes@...solutions.net>,
	Julia Lawall <julia.lawall@...6.fr>,
	Jay Schulist <jschlst@...ba.org>,
	Daniel Borkmann <dborkman@...hat.com>,
	Alexei Starovoitov <ast@...mgrid.com>
Subject: Re: Linux Firmware Signing

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@...ux.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@...e.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.



Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)