[PATCH bpf-next v5 5/7] bpf: lsm: Initialize the BPF LSM hooks

Stephen Smalley stephen.smalley.work at gmail.com
Tue Mar 24 14:51:32 UTC 2020


On Tue, Mar 24, 2020 at 10:42 AM KP Singh <kpsingh at chromium.org> wrote:
>
> On 24-Mär 10:37, Stephen Smalley wrote:
> > On Mon, Mar 23, 2020 at 9:52 PM KP Singh <kpsingh at chromium.org> wrote:
> > >
> > > On 23-Mär 18:13, Casey Schaufler wrote:
> > > > Have you given up on the "BPF must be last" requirement?
> > >
> > > Yes, we dropped it for as the BPF programs require CAP_SYS_ADMIN
> > > anwyays so the position ~shouldn't~ matter. (based on some of the
> > > discussions we had on the BPF_MODIFY_RETURN patches).
> > >
> > > However, This can be added later (in a separate patch) if really
> > > deemed necessary.
> >
> > It matters for SELinux, as I previously explained.  A process that has
> > CAP_SYS_ADMIN is not assumed to be able to circumvent MAC policy.
> > And executing prior to SELinux allows the bpf program to access and
> > potentially leak to userspace information that wouldn't be visible to
> > the
> > process itself. However, I thought you were handling the order issue
> > by putting it last in the list of lsms?
>
> We can still do that if it does not work for SELinux.
>
> Would it be okay to add bpf as LSM_ORDER_LAST?
>
> LSMs like Landlock can then add LSM_ORDER_UNPRIVILEGED to even end up
> after bpf?

I guess the question is whether we need an explicit LSM_ORDER_LAST or
can just handle it via the default
values for the lsm= parameter, where you are already placing bpf last
IIUC?  If someone can mess with the kernel boot
parameters, they already have options to mess with SELinux, so it is no worse...



More information about the Linux-security-module-archive mailing list