Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USB Sharing #110

Open
IDerr opened this issue Dec 9, 2022 · 3 comments
Open

USB Sharing #110

IDerr opened this issue Dec 9, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@IDerr
Copy link

IDerr commented Dec 9, 2022

Hello,

Is is planned to add usb proxy feature between client and server ?

Thanks a lot for your work !

@serpilliere
Copy link
Contributor

Hi @IDerr !

This is exactly one of the questions we are asking ourselves.
Our initial goal is to have a client/Server that won't compromise the client if the server is owned (by the way, that's why we are currently rewriting the client part to split the video decoder in a separate process, which will be sanboxed, to avoid client compromise if the server craft a special video stream.)

So adding full USB proxying may be a big attack surface opened from the server side.
On the other hand, we have for example (in the usbsas projet https://github.com/cea-sec/usbsas), a (limited subset ) HID server re-written in Rust (in userland) so technically, we could add it on the client side of Sanzu, forward the HID information to the server and inject this with, let say uinputs.

This will allow us to have a kind of support for the HID class with a very limited attack surface added, but giving some interesting USB devices (joystick, pads, ....)

But we will still miss important usb devices like oauth2 token or something like that.
I admit that we also have an implementation of fido2 which is included in the sanzu protocol (not published yet) but there is not real magical generic solution.

I am interesting if you have idea on this general problem.

@serpilliere
Copy link
Contributor

serpilliere commented Dec 10, 2022

Note that if someone really wants full usb support, maybe the use of usbredir is possible.
https://gitlab.freedesktop.org/spice/usbredir

It seems that the mandatory points are (taken from the readme):

  • Provide a libusb device handle for the device
  • Provide write and read callbacks for the actual transport of usbredir data
  • Monitor for usbredir and libusb read/write events and call their handlers

After a quick look at the example (usbredirtestclient, which works over a tcp connection):

  • The read/write callbacks may be added to the Sanzu protocol (via tunnel.proto)
  • The main loop run_main_loop may be added in the sanzu client loop (a bit like the sound or X11 events manager )

@IDerr
Copy link
Author

IDerr commented Dec 12, 2022

Hi, really interesting topic, I think that your point of view is good, at the moment, I think usb redir is a great way to redirect usb devices, it's really a choice between security and features.

I mean I think he can really profit sanzu to have to such features and make a complete vdi solution.

If you need help to implement something, don't hesitate to ping me :)

Thanks for your work

@serpilliere serpilliere added the enhancement New feature or request label Dec 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants