Garrett D'Amore wrote: > 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.
We spent many years telling ISV's to rewrite their apps to use loopback, rather than use things like unix domain sockets/named pipes, in response to complaints about very poor performance of unix domain sockets, verses loopback. IIRC, this was in part because things like SO_SNDBUF/SO_RCVBUF were ignored on unix domain sockets, and because that code path never got the same attention to performance tuning as the IP loopback path did. I don't know if these are still factors today, but that's largely irrelevant - we already told ISVs to change (or design) their apps to use loopback, and it's not reasonable to tell them we changed our minds after they already did it. > 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. Yes, it's messy. Even simply splitting this into two bits (loopback, and non-loopback) doesn't get you where you want to be (although it may be part of a solution). > 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. -- Andrew
