0

I have this simple plugin interface for my custom application.

plugininterface.h:

#ifndef PLUGININTERFACE_H
#define PLUGININTERFACE_H
#include <QString>
class PluginInterface
{
public:
    virtual QString Author() const = 0;
    virtual QString Description() const = 0;
    virtual bool Load() const = 0;
    virtual bool Unload() const = 0;
};
Q_DECLARE_INTERFACE( PluginInterface, "MyPluginInterface" )
#endif // PLUGININTERFACE_H

Now this allows users to make plugins for my program. However I'm worried about possible malicious code that could be put into a plugin. I think it would be really good if there was a way to ensure, that whatever happens inside the plugin, it should:

  1. not be allowed to access the internet.
  2. only operate within the directory of the program it was designed for.
  3. have no access to other programs. (no memory reading/writing operations)

If there is no out of the box solution from QT, then I guess one solution could be to black- or whitelist namespace and libaries. If that is even possible. Hopefully there is something a QT/C++ novice like me can do.

Sora
  • 73
  • 7
  • Why? What's so special about your process that you don't want malicious code in the plugins? How do you enforce this for everything else where your users are very likely to run malicious code? This question lacks necessary detail behind your intentions. There's no way to answer it other than "sorry, can't be done" without knowing what you're up to. – Kuba hasn't forgotten Monica Jul 28 '15 at 17:47
  • There's no out of the box solution for any of these on *any* platform, let alone Qt. If you really need these features, you could [hook](https://en.wikipedia.org/wiki/Hooking) the lowest-level API available on each platform that provides these features and block function calls that don't meet your requirements. – MrEricSir Jul 28 '15 at 20:20
  • The three points I mentioned are unnecessary security risks and not needed to extend my program. – Sora Jul 29 '15 at 15:32

1 Answers1

1

This is essentially impossible without starting up a sandboxed runtime of some sort.

Why do you worry about malicious plugins? Do these plugins come from the internet? Do you worry that your users will download random crap and run it? If they do, then likely they do it already with everything else, and your software should be the least of your worries. Alas, the canonical solution is for your software to enforce plugin signatures, and for your business to have a process of vetting and signing plugins, or at least enforcing standard MS developer signatures on plugin DLLs.

You're basically preventing the user from using your software as they see fit. As a user, I dislike that sort of thing.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313