RE: Progress on GCC plugins ?

["Dave Korn" <dave dot korn at artimi dot com>]

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....