Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Aug 2000
Offline Last Active Today, 08:44 AM

Posts I've Made

In Topic: Expression templates for arguments of different types

Today, 01:21 AM

I strongly advise against doing thing like this in an implicit way, it can cause some truly horribly to locate precision problems.

Make it easy for a user to convert a VectorX from one underlying scalar type to another (explicit constructor, to<newScalar>() member function) but do not do anything based on implicit conversion. If things are of different underlying types, the compiler should scream at you. When you consider the conversion justified it should be easy and simple to explicitly request it. At the same time it should be obvious from the code that such a conversion happens.

In Topic: Thoughts on the Boost.Build system? (as opposed to CMake?)

Yesterday, 01:56 AM

I don't think I ever had that problem. Maybe you are doing something wrong?

Very possibly. All I know is that when I run CMake on various different projects that are not mine, I end up with loads of solution files, with extra solutions like ZERO_CHECK and so forth, and a bunch of other accompanying files and folders, all cluttering up the root directory.

The key problem is probably that you don't do a proper out of source build as JTippetts already suggested. Any build directory of a non-trivial project will be a bit of a mess. CMake has to add a bit on top of what you need there because it needs custom build steps to detect when it has to rerun itself, but compared to what a regular project already needs it's not really much. In all the IDEs I know those are placed rather unobtrusively though.
CMake makes out of source builds easy: you pick a source directory and the build directory where you want to place all generated files and the compiler does its magic (actually there is one generator which puts one extra file outside the build directory but that is only because one IDE cannot deal with it otherwise).
Personally I like to place my build directory as a 'build'-subdirectory of my source directory and set that directory to be completely ignored by source control. Others require the build directory to be completely separate (for example 'D:\projects\myproject' and 'D:\projects\myproject-build'.

In Topic: Using whitelisting to run untrusted C# code safely

05 October 2015 - 10:36 AM

I have some major philosophical problems with the title, I don't see how you can run untrusted code safely in any way.
Either you trust the code and then by definition it's safe enough to run it, or you don't trust the code which means it is unsafe to run by definition. (The latter doesn't need to stop you from running it, it is mostly a slight shift towards expecting malicious behavior by default.)
People have been trying to keep crackers out of systems by doing anything you can imagine and a lot more you didn't yet think of, and so far, in the past 25-30 years, they failed. And that is about systems you can only access remotely, by network cable. You let code run on a CPU inside the machine itself! I believe you're just fooling yourself if you think it can be anywhere near safe if you don't trust the code.
If you want to make the C# code useful, you must give it some power, which means it is exploitable, even if it's just DoS-ing the local system. You can make it difficult to do harm, but in the end, a malicious person with enough motivation or knowledge cannot be stopped.

I strongly object to this line of thought. Let's look at StarCraft (the original) and Warcraft 3. A player could go online and browse for games to play with people. While both games came with premade maps, they also contained powerful map editors. When you entered a game with a map you did not have, you automatically downloaded it (as well as having a thriving ecosystem of sites where users could upload, comment and download maps). Apart from the pure map data the maps could also contain significant amount of scripts (after all, that's where the whole Defense of the Ancients concept came from: a Warcraft 3 map which ended up being popular).
That worked because the map scripts were properly sandboxed and to my knowledge there was never any exploit where the risk to a player was ever more than "it's not fun".

Granted, the OP's initial idea of using C# is probably not feasible (but I already wrote about that and talked about alternatives). Care must be taken to properly sandbox things but it has been done in the past and, especially if you only need a limited scope, it is doable.

In Topic: Using whitelisting to run untrusted C# code safely

05 October 2015 - 01:34 AM

Let's say it like this: I'm pretty certain you cannot break the sandbox without giving a malicious user access to the Lua standard library. The malicious user can still make the Lua VM run out of memory though and the host program has to handle that correctly (mishandled error conditions which usually do not happen are after all a very popular exploit vector). The malicious user can also deadlock a thread unless extra precautions are taken.
Whichever API you inject into Lua (and you have to inject something, unless you just want Lua as a glorified .ini file) must also handle being called in malicious ways.

I don't think you can get much better than Lua for sandboxing purposes though. Out of the box it gives you nothing dangerous and you can control exactly which piece of user code sees what. A lot of other languages can do something like an 'import <feature>' or have access to global objects which you cannot prevent without jumping through a lot of extra hoops.

In Topic: Using whitelisting to run untrusted C# code safely

05 October 2015 - 12:57 AM

I have little experience with C# but I have read into sandboxing a bit in the past. From my knowledge sandboxing works better in some languages than in others (and not at all in a few).

Lua for example should work pretty well because the language constructs available can't be reasonably used to break out of the sandbox or sabotage it. You have to be careful about which 'standard library' functions you give the user though (metatable manipulation and raw* functions are an obvious red flag, but they have a wiki page talking about it).