Security, external libraries

[Jeremy Swigart]

I am considering swapping an interpreted scripting language in a project of mine with some form of just using native c++ code to compile tiny dlls to load and run code from. The motivation is to eliminate entirely the interpreted scripting aspect, the binding aspect, and simplify things down to just exposing virtual interfaces to tiny plugins that can do things with the full speed of running native code.

One of the biggest hurdles to this though is that it blows the lid off the application in the domain of security, which is a serious issue. In a scripting language if you don't bind the IO libraries and such, you can basically sandbox the scripts from being able to do things they shouldn't be doing, like messing with system files, or anything not outside the narrowly defined scope of what the plugin should have access to. If you compile arbitrary c++ code and link it in, someone could write c++ code that includes libraries that do all manner of malicious stuff. I've been trying to think of ways that I could provide a c++ plugin interface but still have some control over security to sandbox what access they can get. If the system relied on them compiling their own dlls, I don't think there is anything I could do to prevent malicious stuff from being coded. However if I used something like Runtime-Compiled C++, perhaps I could accomplish my goals by restricting the linker options only to a library that I have exposed only what I have access to. I haven't yet dug into the linker options of RPC++ but am I correct that this could be done? Ultimately I would not allow even the c standard library I suppose, so the only things they would be able to use are types I expose via the includes and libraries of my own. There are probably holes in this security, but I'm thinking it might be good enough. Maybe I could cover other issues with some preprocessor defines that break pragma library loading and such.

Thoughts?

[Doug Binks]

I've been thinking about this for my own work.

This is do-able, with some caveats. The main one being you can't trust a dll built by someone else. Thus I'd create a build server which handles creating the dll and then signs it. Client code which isn't running with dev permissions then only loads signed dlls.

Next up is the build environment. You'll need to ensure no assembly gets through, and restrict pointers so developers can't call functions using them. This is the part which requires the most work, and likely can't be guaranteed as safe as a script could be. You could likely get a long way with a simple parser to remove offensive stuff though.

An alternative I've been considering is to write a PNaCL plugin with sel_ldr to use the Google Portable Native Client security. However this seems a lot of work.

[Jeremy]

That's why I was wondering how many holes could be 'covered up' if the 'build server' were the application itself, such as via RC++, where you can presumably control the preprocessor and linker settings enough to for example  #define asm and pragma lib keywords into a non working state, and only link with precompiled trusted libraries. I'm guessing it might not cover everything, but not much will outside of some heavy sandboxing technology that I'm not sure I want to add a dependency on.

--
You received this message because you are subscribed to the Google Groups "Runtime-Compiled C++" group.
To unsubscribe from this group and stop receiving emails from it, send an email to runtimecompiledcpl...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Doug Binks]

So long as you only allow code to be distributed as source this could work, but then you'd need to ensure clients installed a compiler, which is a large install on some platforms.