sorry you've missed the point entire, and didn't answer either question.
the shortlist of affected programs is:
dhclient dhcpleased iked route
slaacd bgpd dhcpd dhcrelay
ifstated rad route6d
with your proposal, if any of those programs gets subverted (and depending
on how the pledge is done in those programs, there could be further pledge),
they could change the mtu on an interface.
you want this for one program.
but all of them gain it.
and you didn't question that.
to me, that is sad.
but again your mesage is "i am only concerned with the mtu change in
this one program".
yes, missing the mtu change could matter, but I am really sceptical of
that risk, compared to the next-level tradeoff you proposed.
Stefan R. Filipek <srfili...@gmail.com> wrote:
> > you've failed to ask the two required questions
>
> They were implied (with the security-minded audience in mind). I chose
> brevity.
>
> > If one of them gets subverted, what danger can it cause?
>
> This question matters the most, and the answer really determines if we
> even care about the first implied question.
>
> What is the danger of *getting* (not setting) the current MTU and/or
> hardware maximum MTU value? I certainly hope there is none, as that is
> something externally discernable.
>
>
> On Sun, Nov 20, 2022 at 5:38 PM Theo de Raadt <dera...@openbsd.org> wrote:
> >
> > > 1. Does it make sense to add SIOCGIFHARDMTU (and maybe SIOCGIFMTU too)
> > > to pledge("route")?
> >
> > No, I don't think so.
> >
> >
> > Set it ahead of time.
> >
> > (In particular, you've failed to ask the two required questions: If this is
> > capability is added to all programs that use "route", what is that list
> > of programs? If one of them gets subverted, what danger can it cause?
> > You didn't ask those questions, but only thought of your use case. The
> > answer to your use case, it appears, may be to remove pledge just copy
> > of the program. Feel better now? No, I doubt it...)
> >
