I'm sorry, I forgot to reply to all the first time. I think most people assume VirtualBox behaves consistently, since it's the same executable, it also has the same look/feel to it. Even I wasn't aware that the Manager is running as a normal process.
Mihai On Wed, Sep 26, 2018 at 8:28 PM Klaus Espenlaub <[email protected]> wrote: > Mihai, > > yes, that's known to behave differently - but I thought the original > problem (which was very vaguely worded unfortunately) was about the manager > UI. Which is NOT hardened. > > It's why I explicitly mentioned what we tried (and also stated that the > hardening stuff applies to VM processes only). > > If the reporter would've answered by "you're talking about a different > case" then I would know the context finally. So far we've been stabbing in > the dark what's the issue, and I speculated about it more than enough (see > the comment about the possibility to go for the separate UI option). > > Your help is much appreciated in this thread. > > Klaus > > On 26.09.2018 19:10, Mihai Hanor wrote: > > Hi, > > There's a difference between the VirtualBox Manager window and the VM > window, to which I was referring to. Here's how VirtualBox (latest 5.x test > version) is behaving with the Narrator, on Windows 10 1803 64 bit: > drive.google.com/open?id=1UImV_AfjfbLOGD1rKEhsOpDoRBm4kdT5 > > Regards, > Mihai > > On Wed, Sep 26, 2018 at 3:24 PM Klaus Espenlaub < > [email protected]> wrote: > >> Hi Mihai, >> >> On 25.09.2018 20:21, Mihai Hanor wrote: >> >> Hi Klaus, >> >> When you say that the devs have been working on it, are you referring to >> the 5.2.18 release build, the testing builds or the svn? I've build today a >> svn on Windows 10 and the Windows Narrator is not able to read the VM >> window menu controls. All I hear for it is "pain"/"main" or something >> similar, I'm not sure what it's saying. It's only able to read the VM >> window title. The same thing happens with 5.2.18. >> >> >> The work on accessibility has been during the 5.2 development mainly >> (requiring a new approach since Qt5 manages accessibility quite differently >> than Qt4). And one of our GUI devs just confirmed that both Microsoft >> Narrator and NVDA do a reasonable job with reading the majority of the >> manager UI (which has been the topic so far) from the latest 5.2.19 test >> build (actually a more recent one which isn't available publicly, but there >> were no significant changes in a while). "Reasonable job" means that >> they're correctly reading the text for UI elements where the mouse cursor >> is hovering. >> >> So we'd need more details about what aspect of accessibility isn't >> behaving adequately. >> >> From my perspective (building VirtualBox and crashing things), the fact >> that the OS or the debugger are unable to get a "handle" on the hardened >> process, it's something missing. WER just lets the process exit, because it >> can't attach to it. Windbg also can't attach to the process. I'm only able >> to save a dump when there's no default debugger, when the OS puts a message >> box that the process has crashed, then I start Process Explorer as admin >> and dump the process. I haven't found a way to do automatic process memory >> saving. That's the experience I remember, because I haven't had a crash in >> some time. A build-in crash handler could help users report crashes, it >> could be useful. >> >> >> Debuggers simply have no business in a process doing virtualization work >> (just like random, untrusted DLLs which some applications inject into every >> executable, some of them totally destroying any remaining bit of security, >> interestingly mostly done by apps promising to increase security). They >> could corrupt the state of the VM which can end up trashing kernel memory, >> i.e. being a security issue. So this "loss" is entirely intentional (i.e. >> that the VM process handle which is passed to other parties is seriously >> stripped down). It's a different question what to do for post-mortem >> dumping, because at that point the VM is already effectively dead. But IIRC >> Windows adds a new thread to it, kind of bringing it partially back from >> the dead. Which would again end up being questionable from the security >> perspective. >> >> Klaus >> >> >> Regards, >> Mihai >> >> On Tue, Sep 25, 2018 at 8:52 PM Klaus Espenlaub < >> [email protected]> wrote: >> >>> Wait... is it really confirmed that Narrator can't work with (hardened) >>> VirtualBox either? That would mean our devs must have been testing the >>> wrong thing for quite a while now. It certainly hasn't reached my attention >>> so far. >>> >>> For many reasons we cannot recommend that random people run non-hardened >>> builds. What might be a way out (not with the current builds, they would be >>> affected by hardening) is to ship an additional compilation of the VM UI >>> which is not subject to hardening and can be used solely with the "separate >>> VM/UI process" option which VirtualBox has already. Would bring some minor >>> feature losses, but if that would bring back full accessibility I can see a >>> good justification for spending the necessary time. >>> >>> Klaus >>> >>> On 25.09.2018 19:26, Mihai Hanor wrote: >>> >>> Hello, >>> >>> I'm not a developer, but I have some experience with VirtualBox. The >>> reason why not even Microsoft's narrator is able to work with VirtualBox is >>> the hardening of the VirtualBox process, which is enforced to protect the >>> VM from eavesdropping (I think). You can look at the VirtualBox SDK, but >>> you'll probably not find what you're looking for. Also, integrating the >>> NVDA client controller is probably not going to happen and it doesn't look >>> useful, because it requires VirtualBox to send stuff to NVDA (by looking at >>> the C example), which would require considerable effort to rewrite the GUI. >>> The most achievable task might be to build VirtualBox OSE for Windows, >>> without hardening. A much harder task would be to separate the the >>> frontend/GUI part from the VM process and make the frontend run in a normal >>> process. In the upcoming major release of VirtualBox, it looks like the >>> devs have made a move to separate the VM process, but I'm don't know to >>> what end. The frontend still runs in a hardened process. >>> >>> Regards, >>> Mihai Hanor >>> >>> On Fri, Sep 21, 2018 at 12:30 PM Илья Пащук <[email protected]> >>> wrote: >>> >>>> helo. >>>> >>>> >>>> I'm a nvda (nvaccess.org) screenreader addon developer >>>> >>>> I need the way to get some object text in vbox gui, that unaccessable >>>> by >>>> standard methods. >>>> >>>> are there any api interface to get this info from vbox gui? >>>> >>>> >>>> i'm using python. >>> >>> >
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
