[vbox-dev] Binary client with custom IFramebuffer with 6.1.38

[Rūdolfs Bundulis]

> 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.

> 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?

Best Regards,
Rudolfs Bundulis

On Thu, 13 Oct 2022 at 23:11, Klaus Espenlaub via vbox-dev
<vbox-dev at 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 at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev