Search Linux Wireless

Re: Linux Firmware Signing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxx> 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@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?

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: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux