Re: [Bpf] BPF ISA Security Considerations section

[Watson Ladd <watsonbladd@xxxxxxxxx>]

On Mon, Apr 22, 2024 at 12:06 PM <dthaler1968@xxxxxxxxxxxxxx> wrote:
>
> > -----Original Message-----
> > From: Watson Ladd <watsonbladd@xxxxxxxxx>
> > Sent: Monday, April 22, 2024 12:02 PM
> > To: dthaler1968=40googlemail.com@xxxxxxxxxxxxxx
> > Cc: bpf@xxxxxxxx; bpf@xxxxxxxxxxxxxxx
> > Subject: Re: [Bpf] BPF ISA Security Considerations section
> >
> > On Sat, Apr 20, 2024 at 9:09 AM
> > <dthaler1968=40googlemail.com@xxxxxxxxxxxxxx> wrote:
> > >
> > > Per
> > > https://authors.ietf.org/en/required-content#security-considerations,
> > > the BPF ISA draft is required to have a Security Considerations
> > > section before it can become an RFC.
> > >
> > > Below is strawman text that tries to strike a balance between
> > > discussing security issues and solutions vs keeping details out of
> > > scope that belong in other documents like the "verifier expectations
> > > and building blocks for allowing safe execution of untrusted BPF
> > > programs" document that is a separate item on the IETF WG charter.
> > >
> > > Proposed text:
> > >
> > > > Security Considerations
> > > >
> > > > BPF programs could use BPF instructions to do malicious things with
> > > memory,
> > > > CPU, networking, or other system resources. This is not
> > > > fundamentally
> > > different
> > > > from any other type of software that may run on a device. Execution
> > > environments
> > > > should be carefully designed to only run BPF programs that are
> > > > trusted or
> > > verified,
> > > > and sandboxing and privilege level separation are key strategies for
> > > limiting
> > > > security and abuse impact. For example, BPF verifiers are well-known
> > > > and
> > > widely
> > > > deployed and are responsible for ensuring that BPF programs will
> > > > terminate within a reasonable time, only interact with memory in
> > > > safe ways, and
> > > adhere to
> > > > platform-specified API contracts. The details are out of scope of
> > > > this
> > > document
> > > > (but see [LINUX] and [PREVAIL]), but this level of verification can
> > > > often
> > > provide a
> > > > stronger level of security assurance than for other software and
> > > > operating
> > > system
> > > > code.
> >
> > I would put a reference to the other deliverable to say more. If we think that's
> > suboptimal for publication strategy, maybe we can be more generic about it.
>
> There's nothing that can be referenced yet.  One can only say it's left for future work,
> would you prefer that?

I think keeping the existing references while saying "Future work will address this consideration" is best. Let's give the reader something they can use.

>
> > Often BPF programs are executed on the other side of a reliability boundary, e.g. if
> > you execute a BPF filter saying drop all on your network card, have fun. This isn't
> > different from firewalls and the like, but it's a new risk that people aren't expecting. I
> > think we might also need to call out that BPF security assurance requires careful
> > design and thought about what is exposed via BPF.
> >
> > Sincerely,
> > Watson
>
> Do you have proposed text?

"Exposing functionality via BPF extends the interface between the component executing the BPF and the component submitting it. Careful consideration of what functionality is supposed to be exposed and how that impacts the security properties desired is required."

Does this work? Not sure if we have a good example of this causing problems.
>
> Dave
>


--
Astra mortemque praestare gradatim

-- 
Bpf mailing list
Bpf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/bpf