X server in a container

i want to run all X server instances in containers, most likely with each in its own container. the issue seems to be X getting access to the display hardware. also, X will need to be able to switch virtual console when it is processing such a request.

i currently run multiple users on my display, each with a different instance of X as controlled by dm-tool telling lightdm which to switch to. i assume lightdm needs to run in the main host system since multiple instances of lightdm does not make sense. but dm-tool would be run in the user containers, so the bus they use needs to pass between the host and each container.

suggestions?

I think switching to virtual console is not handled by X.
I don't really understand why do you want to put it into container. Probably this: https://github.com/mviereck/x11docker helps.

i want to increase the level of isolation between users, as well as allow specific users to use specific versions of the run time file space. maybe one user is using an application that works only on 16.04 but not 18.04. i could create the container profile for that user to reference a base of files from 16.04 (used as the overlay lower layer to build their virtual root file system).

X handles switching to virtual console just fine, whether it is in text mode or graphical mode. but, consoles 13 and above must already exist when X starts for those to work.

I think you can switch virtual console(s) without X. X is not required to switch. X does not handle switching.
But anyway, do you need now any help, or ??

i still want to know what is needed to allow X to run entirely inside a container. this may include configuration for the container (i may be using LXC or i may just create a "raw" container) or configuration for X. once i get one working the next goal will be to do this through lightdm for each user as they login.

probably this helps: https://mraw.org/blog/2011/04/05/Running_X_from_LXC/
but it won't be more secure, just because it is running inside LXC (because you need to "work" against that isolation).

There is a guide similar to that one about _x11docker_ but for LXD, https://github.com/bitsandsalsa/lxd_gui_container
It has options to run a separate X server in each container, therefore getting good isolation from the host's X server.

An alternative is to use X2Go, each instance in a separate LXD container, running again a separate X server,
https://blog.simos.info/how-to-use-t...xd-containers/

A third option is to use LXD with Guacamole, https://github.com/bmullan/ciab-remote-desktop

All the above have the disadvantage that you do not get full hardware acceleration for your GPU.
If you really need hardware acceleration, then there are other options.

@simosx how does that X server in the container access the hardware to put an unaccelerated display up? does the kernel just let it happen? can i restrict it to a specific virtual console?

Is firejail a viable alternative for you?

https://firejail.wordpress.com/docum...sic-usage/#x11

Originally Posted by Skaperen @simosx how does that X server in the container access the hardware to put an unaccelerated display up? does the kernel just let it happen?

Acceleration depends on the available video driver. Actually I don't really know, but probably you can use different drivers inside containers. I have never heard about that.

Originally Posted by Skaperen can i restrict it to a specific virtual console?

X will run strictly on the terminal (tty) where it was started from. If you mean /dev/ttyX by that virtual console. From this point of view it is restricted.

If you are speaking about Ctrl-Alt-Fx it is not related to X at all. I think now I understand it, you want to disallow to switch to another X. (If I understand it well) You cannot configure either X or the container, because it is handled by the kernel. Probably you need to modify the kernel.
Actually I do not really understand how do you want to connect different keyboards and mice to the containerized X servers, so hard to say anything.

You may try to use either docker or lxc or anything else, but because of the nature of X (access to the hardware and the kernel) - there are links to see how to do that - you need to "workaround" the problems caused by encapsulation by loosen the security restrictions. So finally you cannot really isolate.

Originally Posted by Skaperen @simosx how does that X server in the container access the hardware to put an unaccelerated display up? does the kernel just let it happen? can i restrict it to a specific virtual console?

In the case of containers described earlier, there is no X server running in the containers.
There are the X client libraries that access a Unix socket (or TCP port :6000), which is the provided on the host.
That Unix socket/port is either that of the host's X server, so you get accelerated GPU,
or it could be something like xpra/Xnest/Xephyr which provide software isolation but may or may not be accelerated.

If you really want to run an X server inside a container, see https://discuss.linuxcontainers.org/...container/5022

X MUST handle the switching if the switch needs to change video mode. the kernel knows nothing about advanced video modes. the kernel does intercept the change and handles the text mode change. but if X is running in a console that the switch leaves or goes to, the kernel signals X to do its part. that may have changed some recently as i have seen some very fast changes from X to a different X with never a pause in between.

the big issue i anticipate with X in a container is how X access the hardware without that becoming a security exposure. a root user in a container needs to be fully confined to that container, including access to video hardware. that would mean the kernel needs to enable that access only for the currently switched-to container.

i don't know if there is any means to pass a text-mode whole console to a container, but i don't need that now that things are overall fast enough to just use X with e terminal window (20 years ago it was not fast enough).

following that link, i find too many things that don't work (such as audio) that i want to consider something else. maybe multiple X servers in the host with all the user specific processes running in a container (different for each) can be sufficiently secure to be worth doing. what i would be looking at is how the container accesses that X process, and only that X process. X can use Unix sockets so that might be the way to go (via a small finite shared file space for each).

FYI, i want to accomplish whatever i end up with, without any mods to the kernel (not even an inserted module) or any package. i want to accomplish this entirely as a configuration.

my thinking so far:

when a user first logs in, lightdm will launch its Xorg server and the first process which will get the access credentials. my code would need to take over (while still effective root). it would launch the container for that user with a way to access only the correct Xorg. it would switch to running inside the container and proceed from there. the user files would have to be mapped in and the system files CoWed in (Copy on Write past tense) unless i develop a means to allow users to choose a system or version (even 32-bit).