On Mon, Jun 12, 2006 at 03:12:40PM -0400, Peter Memishian wrote: > > > But more generally: if you revoke the ability to send and receive > > network packets from what appears to be a "non-networking" > > application, this will also revoke network access from libraries that > > this application calls. Figuring out what's affected by this seems to > > me to be a big part of figuring out how the feature could be used (and > > what it must do in order to be useful). > > I agree, though the same can be said for the existing privileges, which > has always concerned me. The only way I can see for this sort of stuff to > be robust in the face of patching is for certain "interesting" > implementation artifacts to be promoted to be part of the interfaces > themselves, but that may create more architectural problems than it > solves, especially in the long-run.
Particularly when it comes to IPC. But more importantly, I'm not sure we can really restrict IPC at all. You can always use plain regular files for IPC. So if you want a process to be unable to communicate with others that aren't its children/parent, well, you're going to have to well and truly cripple it, and that is bound to break lots of libraries. I don't know that that's a good idea, unless you know you're not using libraries from the point where the IPC basic privileges are dropped. Use cases would help. There's a few in Solaris: pt_chmod, say. ssh-keysign, in particular, seems likely to fall prey to enhancements to OpenSSL where IPC might be used someday for who knows what. _______________________________________________ networking-discuss mailing list [email protected]
