4 ms·

I love this idea but it's broken a bit if webcams and mics can't be used at least for my use-case. If I had some time I'd look into extending that with this pro

I love this idea but it's broken a bit if webcams and mics can't be used at least for my use-case. If I had some time I'd look into extending that with this project.

fsflover 5y ago
Have a look at Qubes OS then : https://qubes-os.org https://qubes-os.org. It's even more secure (hardware VT-d virtualization), with a nice gui and allows to use webcams and microphones securely.
- krageon 5y ago
  No GPU acceleration which makes it (as understandable as the choice is) kind of a pain to use.
  - fsflover 5y ago
    It's fast enough for all normal tasks in my experience. Also, you can make a GPU passthrough.
usr1106 5y ago
Pulseaudio has network support. You should be able to share your microphone. Of course you need to run pulseaudio inside the container, too. So it's no longer an application container, but a system container. I used system containers in the past, they are not always easy. No idea whether it would work with podman. Now that I think about it: The browser obviously uses the display of the host. How? Only over X11 network protocol? That worked in the past, does it still work today? I thought modern browsers would need /dev/dri/? If that is made available, why would Webcams not be possible?
- thefr0g 5y ago
  > Only over X11 network protocol? If you read the examples you'll see that they mount /tmp/.X11-unix in the container, thats where the X-Sessions Unix domain socket is. You can do the same for pulseaudio. But you shouldn't. Use Wayland and Pipewire if you are actually interested in using this as a security measure, since they are built for sandboxing. > I thought modern browsers would need /dev/dri/? They only need it for hw-acceleration. You can also give the container access to it if you need that.
mfontani 5y ago
For the (few) docker-based browser containers I use, I simply bind-mount[1] the relative devices and (in Chrome) it all just works. For Chrome inside a container, I also install the Google Talk plug-in. Unsure if that's still required, but things work well. [1]: i.e. "--group-add plugdev", "--device /dev/hidraw4", "--device /dev/video4", "--device /dev/snd", "--device /dev/sri" and similar
- gigatexal 5y ago
  I almost don't want to ask as I know the answer is likely to be not great but can this also be done on mac?
  - Arnavion 5y ago
    If they're USB devices, you can try tweaking the docker-machine VM definition in whatever hypervisor your Mac uses, so that the devices are mounted directly in the VM and are thus available to containers.
    - gigatexal 5y ago
      of course! that's a good idea.

I love this idea but it's broken a bit if webcams and mics can't be used at least for my use-case. If I had some time I'd look into extending that with this project.

fsflover 5y ago

Have a look at Qubes OS then : https://qubes-os.org https://qubes-os.org. It's even more secure (hardware VT-d virtualization), with a nice gui and allows to use webcams and microphones securely.

krageon 5y ago
No GPU acceleration which makes it (as understandable as the choice is) kind of a pain to use.
- fsflover 5y ago
  It's fast enough for all normal tasks in my experience. Also, you can make a GPU passthrough.

usr1106 5y ago

Pulseaudio has network support. You should be able to share your microphone. Of course you need to run pulseaudio inside the container, too. So it's no longer an application container, but a system container. I used system containers in the past, they are not always easy. No idea whether it would work with podman. Now that I think about it: The browser obviously uses the display of the host. How? Only over X11 network protocol? That worked in the past, does it still work today? I thought modern browsers would need /dev/dri/? If that is made available, why would Webcams not be possible?

thefr0g 5y ago
> Only over X11 network protocol? If you read the examples you'll see that they mount /tmp/.X11-unix in the container, thats where the X-Sessions Unix domain socket is. You can do the same for pulseaudio. But you shouldn't. Use Wayland and Pipewire if you are actually interested in using this as a security measure, since they are built for sandboxing. > I thought modern browsers would need /dev/dri/? They only need it for hw-acceleration. You can also give the container access to it if you need that.

mfontani 5y ago

For the (few) docker-based browser containers I use, I simply bind-mount[1] the relative devices and (in Chrome) it all just works. For Chrome inside a container, I also install the Google Talk plug-in. Unsure if that's still required, but things work well. [1]: i.e. "--group-add plugdev", "--device /dev/hidraw4", "--device /dev/video4", "--device /dev/snd", "--device /dev/sri" and similar

gigatexal 5y ago
I almost don't want to ask as I know the answer is likely to be not great but can this also be done on mac?
- Arnavion 5y ago
  If they're USB devices, you can try tweaking the docker-machine VM definition in whatever hypervisor your Mac uses, so that the devices are mounted directly in the VM and are thus available to containers.
  - gigatexal 5y ago
    of course! that's a good idea.