Keep us up to date, especially if you run into difficulties.
We have quite a few mechanisms by now for getting at the screen
contents: the usual IFramebuffer stuff, then VRDE has its own "backdoor"
for getting the screen contents, and likewise the video recording
feature needs the screen contents.
There has to be a way which works well (and long term) :)
Klaus
On 2022-10-17 11:34, Rūdolfs Bundulis via vbox-dev wrote:
Hi Klaus,
thanks for the pointers, I'll check the code and see if I can rework
my existing stuff to this mode.
Best Regards,
Rudolfs Bundulis
On Fri, 14 Oct 2022 at 18:49, Klaus Espenlaub via vbox-dev
<vbox-dev@virtualbox.org> wrote:
Hi Rūdolfs,
On 2022-10-13 22:45, Rūdolfs Bundulis via vbox-dev wrote:
Hi Rūdolfs,
sorry about the long delay... it's been unbelievably busy.
Hi Klaus,
nice to hear from you again (you helped me out a lot during the
initial development phase years ago). It seems that the issue I was
experiencing whas something related to the setup, after removing vbox
and reinstalling it stuff started to work as it did previously.
Mysterious - but sounds a bit like you accidentally messed up access
rights or some such, causing trouble. Good to hear that you're back in
action. Especially as 6.1 is now 'old', since 7.0 is out since the
beginning of the week. No fundamental changes there either (just new 3D
code, which shouldn't cause trouble).
I wonder if you should actually rethink your approach and go for running
the VM in headless mode, and let your piece of code 'attach' to the
console. This has been introduced in VirtualBox 5.1 already, and it
means that the UI 'showing' the screen content is a separate process,
which doesn't need to be hardened.
With this you mean IConsole::launchVMProcess() ? I could take a look
at that, but then can I inject my own IFramebuffer? Will it still work
cross process the same way? Or am I missing something?
Yes and no - the VM itself can be started (as a headless one) through
the API. This would not bring up your code grabbing the screen contents.
We have at the moment no way to start UI processes other than the ones
which are part of the VirtualBox package currently, but if someone can
come up with a sensible proposal how to make this extensible that's
certainly something we'd be willing to integrate.
Your code (which would be a normal API client, not a VM process any more
since that role is performed by VBoxHeadless) would use
IDisplay::AttachFramebuffer (and IDisplay::DetachFramebuffer) for
getting the framebuffer objects connected to the VM process.
Looks like my memory was incorrect, and it appears that only one
separate UI can be started.
If you're looking for code in the Qt UI which is specific to (or must
not be done...) in separate UI mode then search for isSeparateProcess.
The VBoxSDL frontend code is also still there (but we're not shipping it
any more in the VirtualBox packages), and can serve as a much simpler
example. Search for fSeparate in that code.
Hope that gives enough pointers to at least start thinking about a
different solution - or being able to tell that it's not good enough. If
that's the case then it might need a discussion with the experts in this
code area, ...
Klaus
Best Regards,
Rudolfs Bundulis
On Thu, 13 Oct 2022 at 23:11, Klaus Espenlaub via vbox-dev
<vbox-dev@virtualbox.org> wrote:
Hi Rūdolfs,
sorry about the long delay... it's been unbelievably busy.
On 2022-09-14 18:12, Rūdolfs Bundulis wrote:
Hi,
I had a piece of software using VirtualBox 5.2 that was able to start
a VM and inject itself via the IFramebuffer interface and capture the
displayed bitmap. Due to hardening (even though it was so long ago
that now I am not sure if 5.2 had hardening) I was chowning the
binaries with root and adding the sticky bit and that seemed to work.
The fundamental approach should still work. The hardening rules are the
same as before.
Today I tried to port this to 6.1.38 but sadly when doing the chown +
setuid by root it does not work - I seem to be unable to obtain the
VirtualBox API (w/o the chown + setuid thing I get the expected error:
"VirtualBox kernel driver not accessible, permission problem.
Re-install VirtualBox. If you are building it yourself, you should
make sure it installed correctly and that the setuid bit is set on the
executables calling VMR3Create."
When doing the setuid + chown thing I notice that the VBoxSVC is now
started as root, the /tmp/.vbox-root-ipc seems to be there, what else
should I look at to understand what is failing? Does the root setuid +
chown combo somehow disable the client validation by the runtime or is
this expected and only signed Oracle clients will work? Since sudo
VirtualBox works fine and can start a machien. Is such a setup even
possbile with VirtualBox 6.1.38? Or is my only option here building
w/o hardening?
It should work - but you should've always dropped the root permissions
before talking to the API. Which also should have been the same as long
time ago. Being a VM process is pretty tricky, and requires doing
everything at the right time and with the necessary permissions.
I wonder if you should actually rethink your approach and go for running
the VM in headless mode, and let your piece of code 'attach' to the
console. This has been introduced in VirtualBox 5.1 already, and it
means that the UI 'showing' the screen content is a separate process,
which doesn't need to be hardened.
Your code should be rather similar, and while there's no simple sample
code (the API documentation generally covers it, but probably the
information is too spread out to get you going quickly) it should be
possible to find the relevant code in the VirtualBoxVM code relatively
easily, because it attaches to the headless VM if you specify the
--separate parameter. There can be in principle several attached UI's,
which can come handy in your case, where I assume your custom piece of
code would process the screen content only. You would still need a
proper UI, for getting input events etc etc. for the VM.
Klaus
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
