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

[Klaus Espenlaub]

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