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

[Rūdolfs Bundulis]

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
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev