(02-07-2014, 01:10 PM)Scarlet.Crush Wrote: [ -> ]@electrobrains:
So any software that uses the input from your virtual input devices has to run elevated, is that what your saying? [ie the users shell, any game which uses hardware mouse]
I don't know you from Adam, I asked a question and tbh am not convinced by your responses.
Nope, not at all what I'm saying. I appreciate good advice, but that's not the same as FUD. If you feel like doing a security review of the architecture later, by all means. I've already accounted for the things you've mentioned, but you seem to be pretending that my text does not even exist when you bring up the obvious attack vectors that would be possible if someone were to implement this software with no knowledge of security. Everything you mentioned has been addressed, but you won't read the replies to know that.
@
electrobrains: your only response that in any way addressed my concerns was -
Quote:Why in the world would I install a virtual input driver for HID keyboards/mice/etc. that allows a non-Administrator permission?
Which implies that you are going to force the virtual HID driver to be require Administrator permissions.
I'm interested in how you are going to accomplish this and what the implications are. If your not willing to discuss that ...
(02-07-2014, 02:51 PM)Scarlet.Crush Wrote: [ -> ]@electrobrains: your only response that in any way addressed my concerns was -
Which implies that you are going to force the virtual HID driver to be require Administrator permissions.
I'm interested in how you are going to accomplish this and what the implications are. If your not willing to discuss that ...
How would you like to engage in a proper discussion? You are picking out bits and pieces. I can explain the entire security architecture in detail, its interactions with the Windows user- and kernel-security models. I'm not going to do that while it seems like you just want to pick out bits and pieces of what I write, because nitpicking is not helpful to me in any way. I can't guess at your intent in engaging in this discussion. Are you going to carefully consider the entire response, all at once, if I write a complete security architecture document? If not, that is a waste of my time, because I want to make 1.3 really fantastic instead of worrying about 2.0 right now.
Hi everyone,
I wanted to know if it was possible later to have an option in DS4 Tool to adjust the deadzone josticks of PS4 gamepad?
Sorry in advance if my question has already been asked or is stupid. ^^
Thanks.
@electrobrains: I have contractual obligations with my certificate provider around any binaries signed with my certificate - in this case ScpVBus. I cannot allow ScpVBus to be distributed with any software which breaks any of these obligations.
My specific concern is around the use of vmulti, which you stated was what you intended to use for virtual mouse/trackpad/keyboard input. Looking through the vmulti code, I cannot see anywhere that is security aware, nor any obvious method of making it security aware.
If the DS4Tool is not running, what would be in place that would stop a 3rd party program attaching to and using the driver.
If it's not something that you have looked at in detail, then a "yes, we know it's a potential issue, will be addressed before release" is all I need for now.
(02-07-2014, 05:23 PM)Scarlet.Crush Wrote: [ -> ]@electrobrains: I have contractual obligations with my certificate provider around any binaries signed with my certificate - in this case ScpVBus. I cannot allow ScpVBus to be distributed with any software which breaks any of these obligations.
My specific concern is around the use of vmulti, which you stated was what you intended to use for virtual mouse/trackpad/keyboard input. Looking through the vmulti code, I cannot see anywhere that is security aware, nor any obvious method of making it security aware.
If the DS4Tool is not running, what would be in place that would stop a 3rd party program attaching to and using the driver.
If it's not something that you have looked at in detail, then a "yes, we know it's a potential issue, will be addressed before release" is all I need for now.
Okay, thank you for sharing those details with me so I can see where you're coming from. I'm going to just solve this in the traditional UNIX fashion:
- special device for HID input is created with only Administrator permissions. This is almost certainly a change I need to make.
- DS4 Mapper launches with Administrator privileges for the purposes of: installing the ScpVbus driver, installing the vmulti driver, opening vmulti devices, and being able to force disconnect of Bluetooth devices (although probably there is an unprivileged ioctl)
- all input to DS4 Mapper will be sanitized. The GUI is going to be an unprivileged application communicating in semi-real-time with XML flat files
- standard discretionary access control will handle authorization
I see no reason in particular to want to fork ScpVbus because it's never going to be "trusted" input like HID stuff is in Windows. Can you show me the contract so I can be especially careful?
(02-07-2014, 04:36 PM)Voolpy Wrote: [ -> ]Hi everyone,
I wanted to know if it was possible later to have an option in DS4 Tool to adjust the deadzone josticks of PS4 gamepad?
Sorry in advance if my question has already been asked or is stupid. ^^
Thanks.
This will be in 2.0.
I personally against using extra driver, as i am sure with proper privileges the Win API's allow synthetic mouse/keyboard everywhere in the system.
VNC Protocol is able to do it without creating virtual devices. It's only purpose to let the driver take care of handling touchpad events.
My personal vision for 2.0 is to have event triggered touchDown, touchUp, touchesDown, touchesUp, and drag events that can be overridden
If you're sure VNC can do UAC dialogs, what is the mechanism, then? Whatever it does HAS to use Administrator privileges, at least, anyway. We can't correctly do anything generic with the motion controls unless we expose it as a standard (virtual) HID. We can only do klugey per-game mapping.
Found this:
http://en.wikipedia.org/wiki/User_Interf..._Isolation
I would welcome specific knowledge about how you would work around it more ideally than an Administrator-only vmulti device... At least then we could open it and then drop privileges, but if you just turn off UIPI that seems far more dangerous to me.
(02-07-2014, 10:09 PM)electrobrains Wrote: [ -> ]If you're sure VNC can do UAC dialogs, what is the mechanism, then? Whatever it does HAS to use Administrator privileges, at least, anyway. We can't correctly do anything generic with the motion controls unless we expose it as a standard (virtual) HID. We can only do klugey per-game mapping.
Except for dolphin emulator there are no motion control enabled games on windows.
After the Xinput i working correctly. We could look into emulation and DirectInput devices that has all required Axis for each analog input in the controller. This how motionjoy works they allow emulations of PS2/PS3 device as well as x360 controller. We would just create custom DirectInput device with HID Descriptior that has gyro/accel defined as extra axis.
And if any developers will won't to use DS4 for special projects we will have API that allows a retrieval of motions sensor data directly for any projects through dll. There is no need in vmulti imho.
In my optional our focus has to be on providing generic API that will allow us to build a simple purpose tool that allows you game on PC with DS4. I believe that anything like having motion controls map to axis of 2 nd x360 controller should not be a part of this tool. It should stay as simple as possible for a simple purpose to able to game they way developers meant it to.
Any other adoptions of this API will be a separate projects. If someone wants to control windows or a game it will be up to game developers or project developer to read data directly from controller and bypass Xinput/DirectInput, having native support.
If someone wants to implement let's say Webcam tracking of Lightbar combined with motion sensor it will be up to them to implement it.
If developers let's say of LillyPad plugin decide to add native support of DS4 all they would need is to use dll with API to read the data.
Can you prove to me you can do UAC with DS4 Mapper without something like vmulti and without something like the far-more-heavy-handed uiAccess="true" setting? I don't see what is with the aversion to using a module EXACTLY like ScpVbus, to handle the normal HID side of things.