This is more of a hypothetical whilst I'm debugging some code. Lets say I have an application (called X) that calls out to a lib to send an email over a TLS encrypted SMTP connection, whilst at the same time X is talking to another lib which is establishing another TLS socket through the same libcrypto lib, what's the likelyhood of getting some specific (and weird) condition where one function call would fail with a segfault?
I'm kind of grasping at straws, this code worked fine up until we added the Skype SDK which connects over TLS to the Skype servers, since then we can actually get the issue to be repeatable but I'm a bit baffled as to why. (I'm probably overlooking the obvious, but I'll start with the really weird possibility)
Quite genrally speaking it could be possible - but well written library should be robust to multiple access. You might want to look through documentation to see if their API is reentrant (or even thred-safe).
If it is thread-safe, then (assuming that libcrypto authors didn't make mistake) you can be sure that it's not the reason of the problem.
If it is reentrant, then anything using this lib in two (or more) threads should be synchronized on access (eg. using mutexes), but if parts of code are not written by you and you have no option to modiffy it, then you are stuck. The only thing i can think of would be to use another version of libcrypto, so system creates another, unrelated instance of it's internal structure. This is ugly soultion and might behave weird on user machines.
There's a whole man page dedicated to the usage of the OpenSSL library and threads: man 3 threads. You will need to use this if your application has multiple threads that use the OpenSSL library.
Related
currently i'm developing a native-C nodejs Addon to wrap a 3rdparty closed source c-lib and expose it to nodejs.
So far so good. My solution works and native code can be called and worked with.
One problem arises, when calls to those functions are being made subsequently.
The 3rdParty library seems to alocate always the same struct(?; speak: same place in memory) for it's runtime object.
Can I "sandbox" this 3rdparty-lib somehow?
Is there a pattern to solve this? Maybe specific to nodejs-addon development, 'cause nodejs is single threaded, single process-application.
The general suggestion in such cases seems to run the 3rdParty lib in a seperate Process like stated here for example: Isolating and multiply instantiating a C library in-process
I'm not quite sure how to adapt this pattern to nodejs except creating own nodejs processes as "workers" and comunicate to it via rpc somehow. But this seems a little awkward to me and i don't want to reinvent the wheel.
IMHO spawning different node-processes just for this seems to be the 'ugliest' solution.
But correct me if i'm wrong.
Long story, short question. Thanks for adivce.
This is a very very difficult problem, the only solution I have found is to create many copies of the shared object in a temporary directory (with different names) where your program loads each of them once. Most linkers will not realize they are the same and allow you to load them into different address spaces. However this does rely on the code being position independent AFAIK so may not work. It is also nearly as ugly as using IPC so it is up to you what to do.
I know this may be impossible but I really hope there's a way to pull it off. Please tell me if there's any way.
I want to write a sandbox application in C++ and allow other developers to write native plugins that can be loaded right into the application on the fly. I'd probably want to do this via DLLs on Windows, but I also want to support Linux and hopefully Mac.
My issue is that I want to be able to prevent the plugins from doing I/O access on their own. I want to require them to use my wrapped routines so that I can ensure none of the plugins write malicious code that starts harming the user's files on disk or doing things undesireable on the network.
My best guess on how to pull off something like this would be to include a compiler with the application and require the source code for the plugins to be distributed and compiled right on the end-user platform. Then I'd need an code scanner that could search the plugin uncompiled code for signatures that would show up in I/O operations for hard disk or network or other storage media.
My understanding is that the STD libaries like fstream wrap platform-specific functions so I would think that simply scanning all the code that will be compiled for platform-specific functions would let me accomplish the task. Because ultimately, any C native code can't do any I/O unless it talks to the OS using one of the OS's provided methods, right??
If my line of thinking is correct on this, does anyone have a book or resource recommendation on where I could find the nuts and bolts of this stuff for Windows, Linux, and Mac?
If my line of thinking is incorrect and its impossible for me to really prevent native code (compiled or uncompiled) from doing I/O operations on its own, please tell me so I don't create an application that I think is secure but really isn't.
In an absolutely ideal world, I don't want to require the plugins to distribute uncompiled code. I'd like to allow the developers to compile and keep their code to themselves. Perhaps I could scan the binaries for signatures that pertain to I/O access????
Sandboxing a program executing code is certainly harder than merely scanning the code for specific accesses! For example, the program could synthesize assembler statements doing system calls.
The original approach on UNIXes is to chroot() the program but I think there are problems with that approach, too. Another approach is a secured environment like selinux, possible combined with chroot(). The modern approach used to do things like that seems to run the program in a virtual machine: upon start of the program fire up a suitable snapshot of a VM. Upon termination just rewind to tbe snaphot. That merely requires that the allowed accesses are somehow channeled somewhere.
Even a VM doesn't block I/O. It can block network traffic very easily though.
If you want to make sure the plugin doesn't do I/O you can scan it's DLL for all it's import functions and run the function list against a blacklist of I/O functions.
Windows has the dumpbin util and Linux has nm. Both can be run via a system() function call and the output of the tools be directed to files.
Of course, you can write your own analyzer but it's much harder.
User code can't do I/O on it's own. Only the kernel. If youre worried about the plugin gaining ring0/kernel privileges than you need to scan the ASM of the DLL for I/O instructions.
I am working on a game, and one of the requirements per the licence agreement of the sound assets I am using is that they be distributed in a way that makes them inaccessible to the end user. So, I am thinking about aggregating them into a flat file, encrypting them, or some such. The problem is that the sound library I am using (Hekkus Sound System) only accepts a 'char*' file path and handles file reading internally. So, if I am to continue to use it, I will have to override the c stdio file functions to handle encryption or whatever I decide to do. This seems doable, but it worries me. Looking on the web I am seeing people running into strange frustrating problems doing this on platforms I am concerned with(Win32, Android and iOS).
Does there happen to be a cross-platform library out there that takes care of this? Is there a better approach entirely you would recommend?
Do you have the option of using a named pipe instead of an ordinary file? If so, you can present the pipe to the sound library as the file to read from, and you can decrypt your data and write it to the pipe, no problem. (See Beej's Guide for an explanation of named pipes.)
Override stdio in a way that a lib you not knowing how it works exactly works in a way the developer hasn't in mind do not look like the right approach for me, as it isn't really easy. Implement a ramdrive needs so much effort that I recommend to search for another audio lib.
The Hekkus Sound System I found was build by a single person and last updated 2012. I wouldn't rely on a lib with only one person working on it without sharing the sources.
My advice, invest your time in searching for a proper sound lib instead of searching for a fishy work around for this one.
One possibility is to use a encrypted loopback filesystem (google for additional resources).
The way this works is that you put your assets on a encrypted filesystem, which actually lives in a simple file. This filesystem gets mounted someplace as a loopback device. Password needs to be supplied at attach / mount time. Once mounted, all files are available as regular files to your software. But otherwise, the files are encrypted and inaccessible.
It's compiler-dependent and not a guaranteed feature, but many allow you to embed files/resources directly into the exe and read them in your code as if from disk. You could embed your sound files that way. It will significantly increase the size of your exe however.
Another UNIX-based approach:
The environment variable LD_PRELOAD can be used to override any shared library an executable has been linked against. All symbols exported by a library mentioned in LD_PRELOAD are resolved to that library, including calls to libc functions like open, read, and close. Using the libdl, it is also possible for the wrapping library to call through to the original implementation.
So, all you need to do is to start the process which uses the Hekkus Sound System in an environment that has LD_PRELOAD set appropriately, and you can do anything you like to the file that it reads.
Note, however, that there is absolutely no way that you can keep the data inaccessible from the user: the very fact that he has to be able to hear it means he has to have access. Even if all software in the chain would use encryption, and your user is not willing to hack hardware, it would not be exactly difficult to connect the audio output jack with an audio input jack, would it? And you can't forbid you user to use earphones, can you? And, of course, the kernel can see all audio output unencrypted and can send a copy somewhere else...
The solution to your problem would be a ramdisk.
http://en.wikipedia.org/wiki/RAM_drive
Using a piece of memory in ram as if it was a disk.
There is software available for this too. Caching databases in ram is becoming popular.
And it keeps the file from being on the disk that would make it easy accessible to the user.
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).
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).
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.
I'd like to the ask guys with experience in Firebird and IBPP (especially the latter). I found a lot of positive posts about Firebird but I'm having a problem to decide about IBPP. The interface itself is clean and simple but it seems that the project does not have much of activity going on (maybe because it's very stable).
Would you recommend IBPP for production environment?
Is it thread-safe?
Any known bugs?
Thanks.
In addition to the points Milan mentioned:
There is currently no way to use more than one client library when connecting to different databases, or even to specify which client library will be used. There is a certain hard-coded sequence of client library locations that are probed, and the first one that is found will be used for all connections. An IBPP version changing this has been hinted at for a very long time, but hasn't arrived yet. SVN trunk contains some code to deal with this, but I'd say that's alpha quality at most.
And all of this holds true for Windows only, as on all other platforms the Firebird client library isn't loaded at runtime anyway.
The library isn't thread-safe. That doesn't matter for the most part, as you should let each thread have its own connection, transaction and other assorted objects anyway. But IBPP uses its own smart pointer implementation, which is neither completely exception-safe nor thread-safe. Still, as long as you initialize the library from the main thread (before any other thread is created) and create and destroy IBPP objects in the same thread (so absolutely no sharing of objects with other threads!) using IBPP in multiple threads should work fine.
If you can live with the points above (they may not matter to you, at all) it is certainly ready for production use. You can always change things you run into, as we did for FlameRobin too.
IBPP is very stable and I would recommend it for production. That is, if you're going to use it for regular applications.
If you want to build an admin tool or something similar, then be prepared to go inside and get your hands dirty as some of the newer features (i.e. Firebird 2.5 stuff) that are not SQL but API improvements are not supported. For example, it is missing a layer that would expose the new trace API.
Anyway, go ahead and I use it. I have a bunch of IBPP applications in production for years, and, as Douglas wrote, FlameRobin is using IBPP and it works flawlessly (at least as far as DB layer is concerned).
The only thing to be careful about is NUMERIC fields, which are internally stored as integer+scale in Firebird. IBPP exposes those via C/C++ "double", but also via 16/32/64bit integer. So be very careful when retrieving such values, as you will get no warning. For example, if you have DECIMAL(18,2) field with value 254.00 in it, and you accidentaly read that into an integer, you will get 25400, not 254. Make sure you either read those in as double or scale yourself later. This is useful because you can safely convert 25400 to string and then add a decimal point, so you don't lose precision with double (it all depends on the kind of your application and which digits count, of course).
I can't really tell from experience because I've never used IBPP.
But apparently it's used by the flamerobin project so I'd trust it to be 'stable enough'.