Peter Memishian wrote:
> > > I could see doing this on a subset of well-controlled applications, but
> > > what happens when a customer using this facility wants some Sun-supported
> > > application that happens to use loopback inet IPC to "work"? Are we
> going
> > > to change the code to accommodate their need, or tell them they're off
> the
> > > reservation?
> >
> > How would this be any different than if they tried removing other basic
> > privileges, like the ability to fork() or exec(), from apps that really
> > needed it? If customers break their system, it's broken.
>
> The difference is that removing the ability to fork() and exec() does
> exactly that. This privilege removes the ability to communicate on the
> network, and removes one of the mechanisms for IPC that has nothing
> inherently to do with communicating on the network.
>
Its unfortunate that applications use loopback to do their own local
IPC. Such applications are inherently busted IMO (unless they are
*intended* to operate over the network as well as locally), since they
rely on a correct network configuration and wind up utilizing a lot of
extra overhead associated with TCP/IP that a simpler IPC could elide.
I am starting to think that this well-intentioned idea needs to be
rethought, but I'm not sure how to best to deal with it. (I can think
of some unusual mechanisms ... like only allowing programs to
communicate to non-privileged local host ports if they lack the
necessary privilege), but I'm pretty sure that there are holes in these,
and the challenge of making this work "correctly" without either making
it "hard to understand", or not-useful seems not-obvious to me.
I'm starting to think a derail might be in order, but I'd like to know
how the other members feel. I'm neither the foremost security nor the
foremost networking member of PSARC, so I'll just defer to the
decision(s) made by those individuals.
- Garrett
