How insecure is --hostdisplay

[sandrokeil]

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:

x11docker WARNING: Option --hostdisplay with trusted cookies provides
QUITE BAD CONTAINER ISOLATION !
Keylogging and controlling host applications is possible!

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

[mviereck]

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 xdotooland 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.

[sandrokeil]

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.

x11docker.log

On the second run it starts without the full screen "Weston Compositor - X1" window and has no GPU support. See this log.

x11docker-2.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:

x11docker-3.log

Another hint: I don't use GDM (GNOME display manager) at the moment, i start the gnome shell via startx from the tty.

[mviereck]

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.

[sandrokeil]

The xhost not available warning works. I've installed xvfb and xpra session starts but it crashes (youtube) after some seconds, see this logs.

x11docker.log

I've also installed xhost and it is used as expected. Here are the logs

x11docker-2.log

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?!

[mviereck]

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: use --dbus-system
• ALSA: use --alsa or --pulseaudio
• shared memory: use --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.

[sandrokeil]

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.

x11docker.log

Thank you for your support 👍

[mviereck]

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.

[mviereck]

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.