Re: [RFC] Proposal: Static SECCOMP Policies

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

 



wrt. BPF on Android:

(a) eBPF should already be locked down to just the bpfloader boot time process.

If you can prove it isn't, please let us know, but as this is sepolicy
around the bpf(BPF_PROG_LOAD) system call, it should be pretty
airtight:

allow bpfloader self:bpf { ... prog_load ... };
...
neverallow { domain -bpfloader } *:bpf prog_load;

(basically the only exception to the above is root/su on userdebug/eng
builds, which runs sepolicy in permissive mode and thus doesn't
enforce the above - but that obviously doesn't matter for user builds)

(b) cBPF [classic BPF, internally the kernel translates this to eBPF]
is still allowed, for both seccomp() and normal old style socket
filters

- bpf seccomp() is to the best of my knowledge used by normal play
store updatable applications (including the chrome web browser) for
sandboxing (of rendering processes), as such it would be basically
impossible to lock it down (as apps update independently of the rest
of the system) - and would probably be a net loss for security if you
did lock it down / break it...

If you wanted to pursue this you'd need to get agreement from Chrome &
other applications and provide some 'better' alternative.  Likely some
sort of hard coded seccomp version that blocks things that most
sandboxing apps agree is beneficial to block...

(bpf seccomp() is also used by the Android zygote itself to block
various extra system calls from processes/apps it spawns, but as this
list is hardcoded at build time, it's not actually a problem)

- similarly old style BPF socket filters are 'normal' 'ancient'
BSD/Unix/Linux API.  They're used in the (privileged) network stack
itself (which is mainline updatable via the play store, including the
cbpf code), but could also AFAIK be used by random play store
applications - filtering on sockets is truly ancient api.
https://www.tcpdump.org/papers/bpf-usenix93.pdf is from 1992

-

Is there some eBPF program loading API I'm not aware of that we thus
haven't blocked?

On Thu, Sep 12, 2024 at 1:57 PM Neill Kapron <nkapron@xxxxxxxxxx> wrote:
>
> On Thu, Sep 12, 2024 at 04:02:53PM +0000, Maxwell Bland wrote:
> > (Resending as plaintext for msm-kernel mailing list.
> > Original message was intended for android kernel team
> > though msm-kernel should be aware.)
> >
> > Hi Kernel Team,
> >
> > + Kees, Andy, and Will since their input may be valuable.
> >
> > It has been a while! (~9 months to be exact). This January, I sent out a small
> > message on BPF code loading ("unprivileged BPF considered harmful" or something
> > like that). In it, I noted new BPF programs are compiled all the time and
> > thrown into the kernel. At the time, I did not know these programs were just
> > compiled seccomp filter policies, loaded in as new BPF programs continuously
> > through the libminijail interface as well as direct syscall. As of two days
> > ago, I now know this (and now you do too, if not already).
> >
> > OK, yes, syscall filtering is very important, but this is creating a catch-22
> > issue. For one, see step (4) under "Exploitation overview" for
> > https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-local-privilege-escalation-linux.txt.
> > Second, this minor lack of caching is adding load time to more than 90
> > binaries/services on the standard QCOM baseline—I'll admit, it is probably
> > negligible in the grand scheme of things (a quick approximation puts the data
> > operated on around 0.1188 MB). But most importantly, third, without some degree
> > of provenance, I have no way of telling if someone has injected malicious code
> > into the kernel, and unfortunately even knowing the correct bytes is still
> > "iffy", as in order to prevent JIT spray attacks, each of these filters is
> > offset by some random number of uint32_t's, making every 4-byte shift of the
> > filter a "valid" codepage to be loaded at runtime.
> >
> > You might be thinking, "but wait, bionic's libc only defines a couple of
> > restricted policies, primary and secondary for system and user apps
> > respectively." I know! For the most part, apps fall into either what I presume
> > is the default app/system policies, but there are lots of QCOM binaries and
> > other magic programs (dolby dax) that are sending up these programs as well.
> > I'm seeing more than 20 different programs for around a minute's worth of
> > runtime. One example is attached at the end.
> >
> > So, the proposal: a "CONFIG_SECCOMMP_STATIC_POLICY" for seccomp. This
> > would change the Android kernel's generic SYS_seccomp call, which takes in a
> > filter with an array of BPF instructions, to instead reference an ID which
> > corresponds to a fixed file on /sys/bpf/seccomp or something like that. The
> > sandboxing behavior of these apps should be known at compile-time, even if
> > there are multiple "permission set types" that may need to be dispatched. User
> > apps should always have a single, fixed policy. This way it is possible to say
> > for every code page loaded into the kernel where it came from and what it
> > should look like.
> >
> > Unfortunately, I do not know Motorola has enough "weight" to convince QCOM to
> > do the right foundational thing here, or to "define" the seccomp APIs for
> > Android, so it would be good to have Google's buy in, know if there are plans
> > to fix this issue, or some discussion of how to best fix the problem? If
> > anything, a contact at QCOM that might be able to actually hunt down and
> > document valid bytes for these policies?
> >
> > The end goal is simple: when we see a code page is allocated in the kernel, we
> > can be sure that (1) it isn't malicious and (2) has not been modified in
> > transit. I'm fine putting code where my mouth is, but right now that code
> > would involve having to fingerprint the signatures loaded by Qualcomm
> > components every time a new one is released, or pinging Google with a huge
> > patch changing how seccomp works with no idea of what requirements QCOM may
> > have on seccomp policy generation.
> >
> > Thoughts? Is this doable, and if not, why? I'd also love help with the code and
> > adapting existing minijail code to use a new, more integrity-preserving
> > interface. If I am mistaken and it is possible to grab out valid BPF policy
> > code at compile time, please let me know how!
> >
> > Regards,
> > Maxwell Bland
> >
> > Standard filter, (from, for example, com.google.android.gms)
> > "ac00000000000000ac77000000000000bf160000000000006160040000000000b4020000b70000c01d20020000000000b4000000000000009500000000000000616000000000000055000200cb000000b40000000000ff7f95000000000000005500020019000000b40000000000ff7f950000000000000055000200ce000000b40000000000ff7f950000000000000055000200c6000000b40000000000ff7f95000000000000005500020042000000b40000000000ff7f950000000000000055000100de00000005007b000000000055000200d7000000b40000000000ff7f950000000000000055000200d8000000b40000000000ff7f950000000000000055000100e200000005008f000000000055000200a7000000b40000000000ff7f95000000000000005500020038000000b40000000000ff7f95000000000000005500020062000000b40000000000ff7f95000000000000005500020039000000b40000000000ff7f9500000000000000550002003f000000b40000000000ff7f95000000000000005500020040000000b40000000000ff7f95000000000000005500020050000000b40000000000ff7f9500000000000000550002004e000000b40000000000ff7f9500000000000000550002002c000000b40000000000ff7f95000000000000005500020043000000b40000000000ff7f9500000000000000550002001d000000b40000000000ff7f95000000000000005500020030000000b40000000000ff7f95000000000000005500020071000000b40000000000ff7f950000000000000055000200ae000000b40000000000ff7f950000000000000055000200a3000000b40000000000ff7f95000000000000005500020086000000b40000000000ff7f95000000000000005500020042000000b40000000000ff7f950000000000000055000200e9000000b40000000000ff7f9500000000000000550002003e000000b40000000000ff7f95000000000000005500020087000000b40000000000ff7f95000000000000005500020019000000b40000000000ff7f9500000000000000550002005c000000b40000000000ff7f95000000000000005500020016010000b40000000000ff7f950000000000000055000200dc000000b40000000000ff7f95000000000000005500020060000000b40000000000ff7f950000000000000055000200dd000000b40000000000ff7f95000000000000005500020078000000b40000000000ff7f9500000000000000550002005e000000b40000000000ff7f9500000000000000550002008b000000b40000000000ff7f95000000000000005500020080000000b40000000000ff7f950000000000000055000200cb000000b40000000000ff7f950000000000000055000100c600000005004c0000000000550002005d000000b40000000000ff7f950000000000000055000200ac000000b40000000000ff7f95000000000000005500020084000000b40000000000ff7f9500000000000000550002008c000000b40000000000ff7f9500000000000000550002003d000000b40000000000ff7f95000000000000005500020017000000b40000000000ff7f9500000000000000b400000000000300950000000000000005000000000000006160200000000000630afcff000000006160240000000000630af8ff00000000450003000000000061a0fcff0000000045000100040000000500010000000000050001000000000005000e000000000005000000000000006160200000000000630afcff000000006160240000000000630af8ff00000000450003000000000061a0fcff0000000045000100020000000500010000000000050001000000000005000300000000000500000000000000b40000000000030095000000000000000500000000000000b40000000000ff7f950000000000000005000000000000006160200000000000630afcff000000006160240000000000630af8ff00000000450003000000000061a0fcff0000000045000100040000000500010000000000050001000000000005000e000000000005000000000000006160200000000000630afcff000000006160240000000000630af8ff00000000450003000000000061a0fcff0000000045000100020000000500010000000000050001000000000005000300000000000500000000000000b40000000000030095000000000000000500000000000000b40000000000ff7f950000000000000005000000000000006160100000000000630afcff000000006160140000000000630af8ff00000000550002000000000061a0fcff000000001500010001000000050001000000000005000300000000000500000000000000b40000000000030095000000000000000500000000000000b40000000000ff7f9500000000000000",
> > Unknown filter (from QCOM's /vendor/bin/qesdk-secmanager)
> >  "ac00000000000000ac77000000000000bf160000000000006160040000000000b4020000b70000c01d20020000000000b4000000000000009500000000000000616000000000000055000200cb000000b40000000000ff7f95000000000000005500020019000000b40000000000ff7f950000000000000055000200ce000000b40000000000ff7f950000000000000055000200c6000000b40000000000ff7f95000000000000005500020042000000b40000000000ff7f950000000000000055000100de00000005007e000000000055000100e2000000050098000000000055000200d7000000b40000000000ff7f950000000000000055000200a7000000b40000000000ff7f95000000000000005500020062000000b40000000000ff7f9500000000000000550002001d000000b40000000000ff7f95000000000000005500020038000000b40000000000ff7f9500000000000000550002003f000000b40000000000ff7f95000000000000005500020039000000b40000000000ff7f95000000000000005500020050000000b40000000000ff7f9500000000000000550002004e000000b40000000000ff7f9500000000000000550002004f000000b40000000000ff7f950000000000000055000200d8000000b40000000000ff7f95000000000000005500020043000000b40000000000ff7f9500000000000000550002002c000000b40000000000ff7f95000000000000005500020087000000b40000000000ff7f95000000000000005500020086000000b40000000000ff7f95000000000000005500020030000000b40000000000ff7f950000000000000055000200ae000000b40000000000ff7f95000000000000005500020016010000b40000000000ff7f95000000000000005500020019000000b40000000000ff7f95000000000000005500020042000000b40000000000ff7f950000000000000055000200dc000000b40000000000ff7f9500000000000000550002005e000000b40000000000ff7f9500000000000000550002007b000000b40000000000ff7f9500000000000000550002005d000000b40000000000ff7f950000000000000055000200ac000000b40000000000ff7f95000000000000005500020084000000b40000000000ff7f950000000000000055000200a3000000b40000000000ff7f95000000000000005500020080000000b40000000000ff7f95000000000000005500020078000000b40000000000ff7f950000000000000055000200dd000000b40000000000ff7f950000000000000055000100c600000005005800000000005500020060000000b40000000000ff7f9500000000000000550002008b000000b40000000000ff7f950000000000000055000200cb000000b40000000000ff7f95000000000000005500020071000000b40000000000ff7f95000000000000005500020040000000b40000000000ff7f9500000000000000550002003b000000b40000000000ff7f950000000000000055000200e9000000b40000000000ff7f950000000000000055000200b2000000b40000000000ff7f9500000000000000550002008c000000b40000000000ff7f950000000000000055000200d8000000b40000000000ff7f9500000000000000b400000000000300950000000000000005000000000000006160200000000000630afcff000000006160240000000000630af8ff00000000450003000000000061a0fcff0000000045000100040000000500010000000000050001000000000005000e000000000005000000000000006160200000000000630afcff000000006160240000000000630af8ff00000000450003000000000061a0fcff0000000045000100020000000500010000000000050001000000000005000300000000000500000000000000b40000000000030095000000000000000500000000000000b40000000000ff7f950000000000000005000000000000006160200000000000630afcff000000006160240000000000630af8ff00000000450003000000000061a0fcff0000000045000100040000000500010000000000050001000000000005000e000000000005000000000000006160200000000000630afcff000000006160240000000000630af8ff00000000450003000000000061a0fcff0000000045000100020000000500010000000000050001000000000005000300000000000500000000000000b40000000000030095000000000000000500000000000000b40000000000ff7f950000000000000005000000000000006160100000000000630afcff000000006160140000000000630af8ff00000000550002000000000061a0fcff000000001500010001000000050001000000000005000300000000000500000000000000b40000000000030095000000000000000500000000000000b40000000000ff7f9500000000000000",
> >
> > List of services loading seccomp filters pulled from one run of the phone:
> > com.google.android.deskclock
> > /vendor/bin/qesdk-secmanager
> > media.hwcodec/vendor.qti.media.c2@1.0-service
> > media.audio.qc.codec.qti.media.c2audio@1.0-service
> > /vendor/bin/vendor.qti.qspmhal-service
> > /vendor/bin/qsap_sensors
> > media.extractoraextractor
> > /system_ext/bin/perfservice
> > /vendor/bin/wfdhdcphalservice
> > /vendor/bin/wifidisplayhalservice
> > /vendor/bin/qsap_dcfd
> > /vendor/bin/qms
> > /vendor/bin/qsap_location
> > /vendor/bin/qsap_qapeservice
> > /vendor/bin/wfdvndservice
> > media.swcodecoid.media.swcodec/bin/mediaswcodec
> > /vendor/bin/hw/qcrilNrd
> > qsap_qms_13qms16
> > qsap_qms_24qms17
> > /vendor/bin/ATFWD-daemon
> > /vendor/bin/hw/sxrservice
> > /vendor/bin/hw/qcrilNrd-c2
> > system_server
> > /vendor/bin/qmi_motext_hook1013170
> > /vendor/bin/qmi_motext_hook1013171
> > /vendor/bin/ims_rtp_daemon
> > com.android.systemui
> > webview_zygote
> > com.dolby.daxservice
> > vendor.qti.qesdk.sysservice
> > org.codeaurora.ims
> > com.android.se
> > com.android.phone
> > com.qti.qcc
> > com.google.android.ext.services
> > com.google.android.gms
> > com.google.android.euicc
> > com.google.android.googlequicksearchbox:interactor
> > com.google.android.apps.messaging:rcs
> > com.android.nfc
> > com.qualcomm.qti.workloadclassifier
> > com.qualcomm.location
> > com.google.android.gms.unstable
> > com.thundercomm.ar.core
> > com.android.vending:background
> > com.android.vending:quick_launch
> > com.android.dynsystem
> > com.android.managedprovisioning
> > com.android.shell
>
>
> + Jeff, Alistair, and Maciej
>
> Maxwell,
>
> Thanks for the details on this, I have added several people who may be
> better suited to comment on this.
>
> Neill





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux