Closed sandrokeil closed 6 years ago
Does this mean it's less secure than running chromium on host system?
In general, --hostdisplay --clipboard --gpu
is almost identical to run directly on host.
The X11 protocol allows keylogging and remote control of other applications (compare xdotool
and xinput test
). If that is not an issue for you, this setup has the best performance and least overhead.
The goal of x11docker is to provide isolation from host as good as possible, therefore the warning.
It is on you to trust or distrust an image and the application. Personally i distrust internet browsers as I imagine they may access X with javascript in some way and e.g. grab passwords.
Option --gpu
allows access for (web) applications to GPU video RAM that can contain private content.
By the way, any chance to get rid of the --no-sandbox chromium option or does it not matter in the container?
The sandbox features of chromium only work with capabilitiy SYS_ADMIN
. It is nearly root equivalent. You can add it with option --sys-admin --cap-default
.
You have the choice between either good isolation from host with chromium --no-sandbox
or with quite bad isolation from host but good browser tab isolation with x11docker options --cap-default --sys-admin
.
This special case, chromium --no-sandbox
with --hostdisplay
may be less secure than running chromium on host. It has full access to host X but with sandboxing disabled.
Though, I am not sure about this, and I don't know what chromium exactly does in sandboxing.
Edit: Running chromium without --no-sandbox
, but x11docker with --sys-admin --cap-default
will be equivalent to run chromium on host.
xpra [...] (extra compositor window where chromium will be painted, no resize / fullscreen support)
That should not be the case, something is wrong here. --xpra --gpu
should run seamless application windows like --hostdisplay
. As dependencies it needs xpra weston Xwayland xdotool
. If you have installed these and still have issues, please show me a logfile.
Though, --xpra --gpu
is not as performant as --hostdisplay --gpu
.
Thanks for your answer. I've installed xpra and on the first run, it starts a full screen "Weston Compositor - X1" window and fails with connection error. See this log.
On the second run it starts without the full screen "Weston Compositor - X1" window and has no GPU support. See this log.
Maybe it's a missing dependency or config?
Edit: If I only use x11docker --verbose --xpra -- sandrokeil/arch-chromium-nvidia:2018.06.01 chromium --no-sandbox
then I get the error Only console users are allowed to run X server
. See this log:
Another hint: I don't use GDM (GNOME display manager) at the moment, i start the gnome shell via startx
from the tty.
Thank you for testing this!
Maybe it's a missing dependency or config?
In the logs I found you have an xpra version with a cookie bug (a warning is shown). x11docker circumvents this with an xhost
setting. But xhost
is not installed on your system, so xpra fails to connect. It is surprising that it succeeds on the second attempt, maybe xpra accessed Xwayland before Xwayland realized that it has a new cookie (race condition).
I've uploaded an update to master branch that checks whether xhost
is available and disables cookie authentication for the buggy xpra version otherwise. You can either update x11docker or install xhost on your system.
has no GPU support
You have a closed source NVIDIA driver. It has serious issues with Wayland, most probably you won't be able to use Wayland at all on your system.
You can install free nouveau driver instead, it supports Wayland. I have included a warning about NVIDIA and Wayland into the update. --gpu
will probably only work with --hostdisplay
and --xorg
.
Only console users are allowed to run X server
This should not happen, x11docker uses a wrapper to avoid this. I will investigate further.
You can install Xvfb
to avoid this issue, x11docker will than use it instead of Xdummy for xpra.
The xhost
not available warning works. I've installed xvfb
and xpra session starts but it crashes (youtube) after some seconds, see this logs.
I've also installed xhost and it is used as expected. Here are the logs
I've tested nouveau first and switched to nvidia because I need CUDA support for video editing, hopefully it works in Docker Container too. As far as I know, NVIDIA is working on EGL to get Wayland support. Maybe XWayland will work better with this in next release of xorg server.
The usability of nouveau + Wayland + XWayland + Weston was not good. There was no seamless window and resize / full screen does not work, If I remember correctly. Have you a better experience with this?
The best would be, If I can use nouveau on host and nvidia / CUDA only in some Docker containers. But at the moment it looks impossible?!
I've installed xvfb and xpra session starts but it crashes (youtube) after some seconds, see this logs.
The logfile shows that chromium itself is crashing while xpra works fine. You can see the chromium output with options --stdout --stderr
instead of --verbose
. You are running chromium-nvidia without --gpu
, maybe it fails therefore (nvidia driver failing without nvidia GPU). The error messages show other failures about dbus and ALSA and missing shared memory, but they do not look fatal.
Did you succeed with the second try/logfile with chromium image w/o nvidia?
Solutions for seen error messages:
--dbus-system
--alsa
or --pulseaudio
--hostipc
I've tested nouveau first and switched to nvidia because I need CUDA support for video editing, hopefully it works in Docker Container too.
It should work with at least --hostdisplay
and --xorg
.
As far as I know, NVIDIA is working on EGL to get Wayland support. Maybe XWayland will work better with this in next release of xorg server.
That would be good news. NVIDIA was not very cooperative in the past, from what I've heard, neither with nouveau nor with Wayland developers.
The usability of nouveau + Wayland + XWayland + Weston was not good. There was no seamless window and resize / full screen does not work, If I remember correctly. Have you a better experience with this?
Option --weston-xwayland
is quite performant, but unfortunately not resizeable. You can run it with option --fullscreen
.
I consider to add an option --sway
for Sway Wayland compositor that would allow more flexibility.
The best would be, If I can use nouveau on host and nvidia / CUDA only in some Docker containers. But at the moment it looks impossible?!
I doubt that this will ever be possible. The core of nvidia driver is a kernel module, and only one of either nvidia or nouveau kernel module can run at a time. Containers use the kernel from host.
Did you succeed with the second try/logfile with chromium image w/o nvidia?
The comand x11docker --xpra --dbus --pulseaudio --hostipc -- sandrokeil/arch-chromium:2018.06.01
works, but not with option --dbus-system
. It is waiting for the container setup to be ready ... Oh wait, it takes almost two minutes and then it's waiting for freedesktop.login1
and some other stuff.
But don't worry, I will stay with --hostdiplay
at the moment.
Thank you for your support :+1:
but not with option --dbus-system. It is waiting for the container setup to be ready ... Oh wait, it takes almost two minutes and then it's waiting for freedesktop.login1 and some other stuff.
Finally I had a look at --dbus-system
issue. Only with arch images it takes so much time. dbus seems to somehow freeze the system. Probably it waits for some timeouts, but does not show any log output. I don't have that issue with images based on other systems like debian or void linux.
No idea what is different with dbus on arch. Maybe it is some dependency on running systemd services.
The next update includes a warning with a hint to use --systemd
instead of --dbus-system
for arch linux images.
Hello Sandro,
regarding the origin question: I have published image x11docker/check
that demonstrates some security and privacy leaks of --hostdisplay
and other options.
You can try e.g. x11docker --hostdisplay --gpu x11docker/check
to get examples of keylogging, remote host control and GPU memory content.
First things first. Thank you very much for this project. I'm able to run chromium with sound / nvidia GPU support like if it's installed on host system.
I use the command
x11docker --clipboard --pulseaudio --gpu -- sandrokeil/arch-chromium-nvidia:2018.06.01 chromium --no-sandbox
The log shows the warning:
Does this mean it's less secure than running chromium on host system? xpra/nxagent doesn't work or looks ugly (extra compositor window where chromium will be painted, no resize / fullscreen support). To be productive, I think
--clipboard
is also needed for each application.By the way, any chance to get rid of the
--no-sandbox
chromium option or does it not matter in the container?Here are the logs x11docker.log