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

[Klaus Espenlaub]

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