[vbox-dev] getting object name in VirtualBox gui

[Mihai Hanor]

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 <klaus.espenlaub at oracle.com>
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 <
> klaus.espenlaub at oracle.com> 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 <
>> klaus.espenlaub at oracle.com> 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 Илья Пащук <ilusha.paschuk at gmail.com>
>>> 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.
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20180926/4a80e3a8/attachment.html>