2

Well, it's a kind of a web server.

I load .dll(.a) files and use them as program modules.

I recursively go through directories and put '_main' functors from these libraries into std::map under name, which is membered in special '.m' files.

The main directory has few directories for each host.

The problem is that I need to prevent usage of 'fopen' or any other filesystem functions working with directory outside of this host directory.

The only way I can see for that - write a warp for stdio.h (I mean, write s_stdio.h that has a filename check).

May be it could be a deamon, catching system calls and identifying something?

add

Well, and what about such kind of situation: I upload only souses and then compile it directly on my server after checking up? Well, that's the only way I found (having everything inside one address space still).

Ben Usman
  • 7,969
  • 6
  • 46
  • 66
  • @Tronic, thanks for 'sandboxing', but what about 'winapi' - it's desirable to be cross-platform (I understand daemon can't be cr-p, so I'd use few realisation in this case for each platform). – Ben Usman Feb 28 '10 at 17:21
  • 3
    I'd run each _module_ in its own process each having a different user account. Also take a look at chroot(). – Alex Jasmin Feb 28 '10 at 17:24
  • Alexandre Jasmin, it's the first think that comes to mind. But it should be inside one address space. That's what I'm trying to goal. – Ben Usman Feb 28 '10 at 17:55
  • @Mlnner: You can't. Memory access controls are controlled at the address-space level. If a thread or function screws up in your process, the process goes ka-boom. There's no way around this. – Billy ONeal Feb 28 '10 at 19:31

2 Answers2

4

As C++ is low level language and the DLLs are compiled to machine code they can do anything. Even if you wrap the standard library functions the code can do the system calls directly, reimplementing the functionality you have wrapped.

Probably the only way to effectively sandbox such a DLL is some kind of virtualisation, so the code is not run directly but in a virtual machine.

The simpler solution is to use some higher level language for the loadable modules that should be sandboxed. Some high level languages are better at sandboxing (Lua, Java), other are not so good (e.g. AFAIK currently there is no official restricted environment implemented for Python).

Jacek Konieczny
  • 8,283
  • 2
  • 23
  • 35
  • 1
    A classic example of bypassing the standard library functions (from the International Obfuscated C Code Contest): http://www1.us.ioccc.org/1984/mullender.c http://www1.us.ioccc.org/1984/mullender.hint – bk1e Feb 28 '10 at 19:03
  • I'm not sure, I've understood write last comment. (E. isn't my native language). @bk1e, here are examples of bypassing 'bad functions' filter? What connects it with obfuscation? – Ben Usman Mar 01 '10 at 13:47
  • A "bad functions" filter would not catch an array of bytes that get executed as machine code. – bk1e Mar 01 '10 at 21:06
1

If you are the one loading the module, you can perform a static analysis on the code to verify what APIs it calls, and refuse to link it if it doesn't check out (i.e. if it makes any kind of suspicious call at all).

Having said that, it's a lot of work to do this, and not very portable.

Magarshak
  • 151
  • 1
  • 4
  • You would have to disallow arrays, or at least find a reliable way to check for buffer overflows. – bk1e Feb 28 '10 at 19:05