On 07 November 2007 17:52, David Edelsohn wrote: > > The concern is the many forms of shim layers that possibly could > be written more easily with a plug-in framework.
I wonder if we could adapt some kind of privsep model, so that once the compiler has finished init, it gives away its rights and can't even open files or create pipes or sockets any more. The gcc.c driver could remain at full user prives and take care of opening everything (a bit like I guess it already does when you're using -pipe?) and cc1 and pals could all be hobbled. Ooooor..... how about we define plugins in an interpreted or bytecoded language and don't allow any IO whatsoever? Oooooorrrr.... if we were really clever we could maybe define an interface that's entirely non-enumerable: it calls out to hooks, providing them with just enough information and interfaces to do the job they have to do, but we don't make it possible to derive information about the overall AST because we don't provide any way to know 'what's out there'. #1 seems like there might too easily be loopholes even assuming it can actually be made to work, that is to say that it would be very hard to really prevent data escaping from the process boundary using the unix fs perms model. Maybe the more modern unices with finergrained acls and kernel object permissions would be able to make work, but I think that the lesson of chroot jails is that they're to prevent fat-finger errors, not determined security attackers. #3 isn't necessarily possible either. It would probably need serious maths formalisms and proofs to define. Zero-knowledge secret problem sharing based plugins, anyone? #2 might well be a goer. It looks pretty plausible. cheers, DaveK [carefully avoiding the IANAL debate :-)] -- Can't think of a witty .sigline today....