Perhaps I am worrying too much. After all, a webserver that doesn't call into to the hypothetical JIT package won't even have that code linked into its binary; so it would not add any attack surface in that case.
And the alternative at the moment is to use a C based mechanism, which will in all cases be less secure than using Go, for all the well known security problems that C has. But still it is an interesting thought exercise, and I did imagine a mechanism for sandboxing JIT generated code, which may be quite desirable in other use cases: The call stack could be marked in some way at the call point entering the newly generated code; if nothing else by the expediency of calling through a particular, distinct function that marks the invocation of extension code. Let's name it "CallJITCode()" for the sake of discussion. This point on the call stack would mark the passage into extension code. Then JIT generated code could, if flagged to be sandboxed, always include in its setup/pre-amble at the beginning of all newly generated functions a check that the callstack above it included the CallJITCode() function. If it was not there, then the code has broken outside the sandbox, and should stop itself. Naturally this would not prevent a) starting go routines with existing functions, nor would it prevent b) using a channel to start processing on another stack. One way a) could be addressed would be by limiting the visibility of sandboxed functions to only packages specified during the JIT code generation. This would also suffice to hide any channels that should be off limits; for if they are not global in package main, and not present in the sandbox-allowed packages, then there would be little means for sandboxed code to access them, since it cannot name them directly. And without reflection or assembly, both of which could be flagged if desired as not-allowed to sandboxed code, there then would be little means of escaping the sandbox. This implies that the usual package specification for Go code might need to be a separate parameter for JIT-ed code. That is to say, the import section should be a separate string from the source code string, so that an attacker would have no way to add arbitrary packages, should the code be sandboxed. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAPNEFAaSUdLP-B-wDi4QK91wSUwB4v9uz7ngMMkcaHTj25qmyA%40mail.gmail.com.
