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