> they could change the mtu on an interface.

No. I'm only proposing the ability to GET the MTU (SIOCG...).

Setting the MTU (SIOCSIFMTU) is currently in "wroute", which slaacd
already has pledged.

On Sun, Nov 20, 2022 at 5:59 PM Theo de Raadt <dera...@openbsd.org> wrote:
>
> the v6 people in the group will consider the v6 aspects.
>
>
> I wanted to comment on the "let's change pledge!" enthusiasm, which is
> again failed to consider the other programs which are affected by such
> a proposed change.  Any proposal must consider the impact in *ALL PROGRAMS*.
> I do this all the time.  I expect others to do this.
>
> Theo de Raadt <dera...@openbsd.org> wrote:
>
> > 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...)
> > > >
> >

Reply via email to