On Fri, Oct 25, 2019 at 02:26:57PM +0000, David Laight wrote:
> From: 'Marcelo Ricardo Leitner'
> > Sent: 25 October 2019 14:22
> > On Fri, Oct 25, 2019 at 09:00:45AM +0000, David Laight wrote:
> > > From: Marcelo Ricardo Leitner
> > > > Sent: 25 October 2019 04:24
> > > ...
> > > > > @@ -5521,8 +5522,16 @@ static int sctp_getsockopt_peer_addr_info(struct sock *sk, int len,
> > > > >
> > > > > transport = sctp_addr_id2transport(sk, &pinfo.spinfo_address,
> > > > > pinfo.spinfo_assoc_id);
> > > > > - if (!transport)
> > > > > - return -EINVAL;
> > > > > + if (!transport) {
> > > > > + retval = -EINVAL;
> > > > > + goto out;
> > > > > + }
> > > > > +
> > > > > + if (transport->state == SCTP_PF &&
> > > > > + transport->asoc->pf_expose == SCTP_PF_EXPOSE_DISABLE) {
> > > > > + retval = -EACCES;
> > > > > + goto out;
> > > > > + }
> > > >
> > > > As is on v3, this is NOT an UAPI violation. The user has to explicitly
> > > > set the system or the socket into the disabled state in order to
> > > > trigger this new check.
> > >
> > > Only because the default isn't to be backwards compatible with the
> > ^^^^^
> >
> > You meant "is", right? Then we're agreeing.
>
> No, I meant isn't.
Then you missed this detail in the patch. The default here IS to be
backwards compatible.
> The application must see a backwards compatible interface unless
> the application itself requests something different.
> The sysadmin can't be allowed to change the API seen by old applications.
Disagree. Sysadmins should be able to harden their systems as much as
they want/need. Yet, if that causes issues with old applications,
that's on them.
>
> AFAICT if the protocol part of PF is enabled (which handles primary path
> failure better than the older version) and ' transport->state == SCTP_PF'
> is true then an old application binary will get a completely unexpected -EACCESS
> rather than a valid state (out of the old valid states) if it requests 'peer addr_info'.
>
> You cannot assume that just because some sysctl is set (because someone
> building a distribution suddenly decided it was a 'good idea') that an
> application binary will not fall in a big heap due to an error condition
> that couldn't ever happen before.
Agree, but that assumption doesn't have a room here. If the
distribution decided to harden the system, that's on them. Ditto for
many many other decisions, like having SELinux policies to block sshd
to bind only on port 22 and so, or for building the kernel without
SCTP_COOKIE_HMAC_MD5 because they think it's weak, etc.
Marcelo
