+ BenM
James, I don't have immediate context on this issue. BenM will be back next
week and he should be able to give you more accurate feedback.
- Jie
On Fri, Apr 7, 2017 at 8:37 AM, James Peach wrote:
>
> > On Apr 5, 2017, at 5:42 PM, Jie Yu wrote:
> >
> > One comment here is that:
> >
> > We plan to support libprocess communication using domain socket. In other
> > words, we plan to make UPID a socket addr. Can we make sure this approach
> > also works for the case where UPID is a unix address in the future? For
> > instance, what will `socket->peer();` returns for domain socket?
>
> I can look into that.
>
> So you would consider this approach a reasonable mitigation?
>
> >
> > - Jie
> >
> > On Wed, Apr 5, 2017 at 3:27 PM, James Peach wrote:
> >
> >> Hi all,
> >>
> >> Currently, libprocess messages contain a UPID, which is send by the peer
> >> in the HTTP message header. There's no validation of this, so generally
> >> messages are trusted to be from the UPID they claim to be.
> >>
> >> As an RFC, I've pushed https://reviews.apache.org/r/58224/. This patch
> >> constrains the UPID to not change for the lifetime of the socket, and
> also
> >> enforces that the the IP address portion of the UPID matches the peer
> >> socket address. This makes UPIDs more reliable, but the latter check
> would
> >> break existing configurations. I'd appreciate any feedback on whether
> this
> >> is worth pursuing at the lib process level and whether people feel that
> >> this specific mitigation is worthwhile.
> >>
> >> thanks,
> >> James
>
>
