Application in a Child Process
-
Question:
Is there any way to run a subordinary child QML application in it's own QQmlEngine in an isolated separate process?Desirable Result:
You'd have your host QML application H acting like a window-manager starting another QML application A in a separate child process, thus isolating it and displaying it onto a certain viewport component inside H's QML code.Reason:
Isolating the subordinary application in it's own system process improves security:- segfaults can't crash the host application
- different virtual memory tables
- etc.
-
Probably this could be accomplished if we share some render buffers of the Qt Quick Scene Graph over shared memory between the child process and the host process and render the application inside the host QML app based on the shared memory resource. Anyone any ideas?
-
@romsharkov Hmm I'm not sure if there's an easy way to do this. No built in one into Qt/QML at least.
Using plugins or shared libs is a way you could execute other code but it would be inside your process.
That being said I'm sure there's a way to grab windows/widgets from other apps and put them into your own. It would not be easy. It would also be platform specific. You would need to write your own code to handle finding and taking reskinning/moving the windows into your own area (per platform).
Anything is possible with a computer and a lot of time on your hands. The question is if it's worth all that time or not? :)
-
@ambershark Spent a lot with the sandboxing and security issues, you should also remember my first thread.
Why
At the QBEON Startup we are developing a cloud operating system that's like Google's ChromeOS but with the difference that it runs on your very own cloud rather than Google's cloud.We decided to use QtQuick as the primary UI frontend technology when chosing between HTML5 and QtQuick. In our opinion QML is the superior technology for modern, responsive, modular, easily maintainable, cross platform GUI applications.
The security concerns arose when we wanted to let 3rd party App developers harness the power of C++ rather than enforcing QML/JavaScript only.
Results
Unfortunatelly we didn't find any way to properly sandbox a C++ based Qt Quick application so far and have no other choice as to restrict app development to QML/JavaScript only, which shouldn't bad at all as QML and the V4 JavaScript engine should theoretically be fast enough for the majority of applications we target and is quite easy to sandbox.Future
I believe there's a way to make C++ available to 3rd party developers for certain calculation-heavy business logic by providing safe interfaces between the QML engine that the 3rd party C++ code must implement in order to communicate properties, invokables, signals & slots to the sandboxed QML app from inside of an isolated separate system process. -
@romsharkov Yea I remember the other thread. :)
If the base for your OS is linux you could pretty easily set up chroot/jail type sandboxes to run applications inside. Even those aren't 100% secure though. Sandboxing is incredibly tough in my opinion.
So you are trying to protect the operating system from 3rd party apps? Or are you trying to protect other people's apps from random 3rd party apps? Either one sounds like you need an OS level sandbox and not really an application level one. In which case you can make use of a chroot jail.
You can also make your own sandbox for the C++ components and then create an interface that allows a Qml or other process to communicate with the sandboxes process.
This is not an easy thing to do though. Expect to spend some serious time engineering/designing it, and expect at least a few large delays as you figure out what works implementation wise.
Maybe even look into something like docker to run the applications. Or some other style of virtualization. That would separate root OS from guest OS. That's how I do kind of impromptu sandboxes when I need to play with likely virus/spyware applications. :)
-
@romsharkov Yea I remember the other thread. :)
If the base for your OS is linux you could pretty easily set up chroot/jail type sandboxes to run applications inside. Even those aren't 100% secure though. Sandboxing is incredibly tough in my opinion.
QubeOS consists of two parts: the client and the cloud itself. The architecture is very similar to Google's ChromeOS where the client is Chrome based (HTML5) and the cloud is GCP (Google Cloud Platform). In our case the client is Qt-based and should run on any Qt-supported platform, that is at least Linux, Windows, Mac, Android and IOS. We can also build devices running our OS exclusivelly for enhanced security (analogy to Chromebooks; Linux-based ofcourse) but generally the client shouldn't actually care on what low-level OS it is running as it is just a cross platform client for a higher level OS, just like Chrome is a higher level client for the GCP and the web in general.
So you are trying to protect the operating system from 3rd party apps? Or are you trying to protect other people's apps from random 3rd party apps? Either one sounds like you need an OS level sandbox and not really an application level one. In which case you can make use of a chroot jail.
Actually both, you don't want applications to harm other apps and the OS itself, therefore you isolate/sandbox them. In case of QML you don't really need OS-level sandboxing as the QQmlEngine is already a sandbox and JavaScript is a high level language with no possibility to access neither memory nor the host system, C++ is what needs OS-level sandboxing. C++ is dangerous by it's nature whereas JavaScript/QML is only dangerous when buggy.
You can also make your own sandbox for the C++ components and then create an interface that allows a Qml or other process to communicate with the sandboxes process.
Yeah, exactly, that's what I mentioned in the previous post. Building a native interface to allow isolated processes running 3rd party C++ stuff to safely communicate with their QML frontend could very likely be possible, the underlying OS would separate their virtual memory spaces (thus eliminating lots of security issues), restrict access to host system's resources through a unified API and things like SEGFAULT's could not shoot down the entire client in case of one application's malfunction. Qt Remote Objects that's currently under development looks promising, yet not sure it's what we are looking for though.
This is not an easy thing to do though. Expect to spend some serious time engineering/designing it, and expect at least a few large delays as you figure out what works implementation wise.
Totaly agree, sandboxing isn't a trivial topic, in fact even one of the hardest. That's why we decided to focus on a QML-only application environment and only consider to add C++ support in the future.
Maybe even look into something like docker to run the applications. Or some other style of virtualization. That would separate root OS from guest OS. That's how I do kind of impromptu sandboxes when I need to play with likely virus/spyware applications. :)
We use Docker for the cloud-side of QubeOS as we (or the user, you may literally host QubeOS yourself and it's even designed to be used that way) run the cloud exclusively on Linux, services and system modules are all containerized and isolated. On the client side though there's no way to use containarization, we have to do it on the application-level and with JavaScript/QML and the QQmlEngine it's manageable.
The only thing I fear is that JavaScript is pretty slow in comparison to well optimized C++, which would drain the battery of mobile devices, and usually JS is much more RAM thirsty. Actually the entire Web is built on JavaScript and all modern mobile devices are optimized for the web at least, but I'm simply not aware of how well optimized the V4 QML/JavaScript engine made by The Qt Company really is... whether QML is mature enough to become an app platform like the web browser. Canonical seems to be confident about QML as they used it as their main programming language for the (canceled) Ubuntu Touch project.
P.S. Mark, nobody needs yet another Android :)
-
not aware of how well optimized the V4 QML/JavaScript engine made by The Qt Company really is... whether QML is mature enough to become an app platform like the web browser
Good question. I'm not sure on that either. I imagine it is pretty well optimized as most things from Qt are. Maybe not initially but QML has been around long enough now to have seen some decent optimizations.
Totaly agree, sandboxing isn't a trivial topic, in fact even one of the hardest. That's why we decided to focus on a QML-only application environment and only consider to add C++ support in the future.
Good call! :) That will let you get going and then give the hard core people speed later on.
Building a native interface to allow isolated processes running 3rd party C++ stuff to safely communicate with their QML frontend could very likely be possible, the underlying OS would separate their virtual memory spaces (thus eliminating lots of security issues), restrict access to host system's resources through a unified API and things like SEGFAULT's could not shoot down the entire client in case of one application's malfunction.
Yep, exactly!
The only thing I fear is that JavaScript is pretty slow in comparison to well optimized C++, which would drain the battery of mobile devices, and usually JS is much more RAM thirsty.
This is a pretty big deal. There is a HUGE difference as I'm sure you know between C++ and JS or QML. The speed difference and battery drain would probably by 20x or so (from my experience anyway). Mostly speed diff, I don't know for sure on battery drain. And the RAM requirements for Java and JS are huge. I threw an Upsource instance (from Jetbrains) on an AWS micro t1 and it didn't have enough ram to run it. It has 2gb. That should have been way more than enough. A similar application to upsource written in C++ would take, I dunno, maybe 100MB? Maybe.. Anecdotal evidence, but it really opened my eyes to the performance issues and requirements of things that are not C/C++. ;)
-
@romsharkov
Hi there,Do I understand correctly that you have managed to run a QQmlProcess in a separate process?
I am asking it because I have came across pretty much the same problem:
https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/pull/79#issuecomment-307348648If you could tell me some words of you implementation details that would be awesome!
Thanks in advance!
