Security Implications for GUIjail with nullfs and xhost +

B

BawdyAnarchist

In exploration of "jail/bhyve everything for security," I have successfully jailed the NIC (soon to bhyve with PCI passthrough), and jailed a VPN tunnel. I'm now considering 2 options for GUI jails:

1. `ssh -Y` between host/jail (definitely secure)
2. `mount_nullfs /tmp/.X11-host` to my jails, with xhost +

Since I jailed the NIC, blocked all traffic to the host, and don't intend to X Forward outside of the physical machine/host, I have this naive hope that ssh is unnecessary and no more secure than option #2.

Is this correct? Or are multiple GUI jails simultaneously sharing /tmp/.X11-unix a recipe for security vulnerabilities?

EDIT: I'm not able to start Falkon, OpenOffice, and getting crashes on many KDE applications. I am thinking that I need to install Qt and KDE to the host, as I'm guessing that many of these libraries require direct access to kernel resources? I'm not sure. I was hoping to avoid installing anything more than X11 to host.
 
BawdyAnarchist said:
In exploration of "jail/bhyve everything for security," I have successfully jailed the NIC (soon to bhyve with PCI passthrough), and jailed a VPN tunnel. I'm now considering 2 options for GUI jails:

1. `ssh -Y` between host/jail (definitely secure)
2. `mount_nullfs /tmp/.X11-host` to my jails, with xhost +

Since I jailed the NIC, blocked all traffic to the host, and don't intend to X Forward outside of the physical machine/host, I have this naive hope that ssh is unnecessary and no more secure than option #2.

Is this correct? Or are multiple GUI jails simultaneously sharing /tmp/.X11-unix a recipe for security vulnerabilities?

EDIT: I'm not able to start Falkon, OpenOffice, and getting crashes on many KDE applications. I am thinking that I need to install Qt and KDE to the host, as I'm guessing that many of these libraries require direct access to kernel resources? I'm not sure. I was hoping to avoid installing anything more than X11 to host.
Click to expand...
I have never tried this as I didn't see the point of doing so. But I have tried to use ssh forwarding to run Firefox with another user account also on my machine and I would say if you just browse sites with mostly text you are fine. But if you want to watch youtube with it, it lagged like hell. I tried to play Supertux2 using this method, too, and it also lagged like hell.

p/s: I do have reasonable performance with xhost and still using xhost to run Firefox and Supertux2 with another user account on my machine to keep my current user account clean, so far without any problems. Of course, I don't care about security, though.
 
chrbr said:
There is an excellent howtodo about running a browser in a jail https://forums.freebsd.org/threads/...-in-a-jail-using-iocage-and-ssh-jailme.53362/. One section is about options related to the communication between the application and the X11 server. There has been no activity in this thread. Therefore it is difficult to find if you do not know about its existence.
Click to expand...

Thanks for the link. I did read through that thread, but I couldn't pick out an answer to the particular questions I have. Namely, whether or not nullfs sharing the X11-unix socket with xhost is a security risk if I don't actually have my host system online. And whether or not installing the full graphical libraries to host is necessary for proper graphical functions in jails.
 
sysctl said:
I have never tried this as I didn't see the point of doing so. But I have tried to use ssh forwarding to run Firefox with another user account also on my machine and I would say if you just browse sites with mostly text you are fine. But if you want to watch youtube with it, it lagged like hell. I tried to play Supertux2 using this method, too, and it also lagged like hell.

p/s: I do have reasonable performance with xhost and still using xhost to run Firefox and Supertux2 with another user account on my machine to keep my current user account clean, so far without any problems. Of course, I don't care about security, though.
Click to expand...

It's segregation of inherently insecure software (browsers, for example) and/or activities. Putting the NIC in a VM with PCI passthrough isolates potential DMA attack vectors that those cards have. IIRC Michael Lucas in one of his books suggests the idea of making the host simply a jail coordinator. Even the system directories of my work jails are freshly derived from clean templates at start. An emulation of the Qubes concept.
 
BawdyAnarchist said:
It's segregation of inherently insecure software (browsers, for example) and/or activities. Putting the NIC in a VM with PCI passthrough isolates potential DMA attack vectors that those cards have. IIRC Michael Lucas in one of his books suggests the idea of making the host simply a jail coordinator. Even the system directories of my work jails are freshly derived from clean templates at start. An emulation of the Qubes concept.
Click to expand...
Pardon me but I still no idea what you are trying to archive. Perhaps something like this?
 
sysctl said:
Pardon me but I still no idea what you are trying to archive. Perhaps something like this?
Click to expand...

Well, my setup is somewhat a different matter than the questions of OP. OP questions are about security implications of nullfs sharing the X11-unix socket (with xhost +), and whether the host needs the graphical libraries installed in order for jails to cleanly run GUI stuff.

But yes, something comparable to EasyOS. Again, it's a security mechanism. You containerize everything, which raises the difficulty of compromising host. Host merely acts as a coordinator for the containers.
 
Dear BawdyAnarchist
BawdyAnarchist said:
Thanks for the link. I did read through that thread, but I couldn't pick out an answer to the particular questions I have. Namely, whether or not nullfs sharing the X11-unix socket with xhost is a security risk if I don't actually have my host system online. And whether or not installing the full graphical libraries to host is necessary for proper graphical functions in jails.
Click to expand...
This is out of my knowledge. In the systems I have I use the X11 on the host as well as by the browser in the jail. Therefore I have never tried to tweak the X11 part of the host to its absolute minimum. I hope someone else can give you more helpful answers.
 
BawdyAnarchist said:
EDIT: I'm not able to start Falkon, OpenOffice, and getting crashes on many KDE applications. I am thinking that I need to install Qt and KDE to the host, as I'm guessing that many of these libraries require direct access to kernel resources? I'm not sure. I was hoping to avoid installing anything more than X11 to host.
Click to expand...

Progress! It occurred to me that the jails didn't have access to my nvidia GPU. So I added 'nvidia*' to my devfs rules. Problems fixed! I'm still throwing a few messages at Falkon launch: "QWebEngineUrlScheme::registerScheme: Too late to register scheme "falkon"", but I'm not sure that's necessarily a problem. My other gui apps seem to be functioning as well.

So now it's just the one question left: Security implications of nullfs sharing the .X11-unix socket
 
anonymous9 said:
Project FiFo started as a management tool for SmartOS. Later, the developers extended it to FreeBSD, but unfortunately, after several releases, it was abandoned and they have continued with their core of SmartOS.

However, one of the interesting concepts they used was nested jails, and the NIC was assigned to the outer jail, which kept the inner jail from making changes.
Click to expand...

That is interesting. Nest the jails for a particular tunnel. At the moment my jails are directly on top of my host with vnet to the desired tunnel.
 
For my Jails I simply mv the /tmp/.X11-host into them. You can't copy a UNIX domain socket but you can move it (if it is on the same filesystem).

Did the nullfs mount work? I have always been interested but never got round to trying.

You probably don't want to mv the .X11-host file into them and back again to launch non-guest programs, so perhaps use Xephyr instead and move that socket into the jail for connection?
 
kpedersen said:
For my Jails I simply mv the /tmp/.X11-host into them. You can't copy a UNIX domain socket but you can move it (if it is on the same filesystem).

Did the nullfs mount work? I have always been interested but never got round to trying.

You probably don't want to mv the .X11-host file into them and back again to launch non-guest programs, so perhaps use Xephyr instead and move that socket into the jail for connection?
Click to expand...

Yes nullfs worked. However, I can't include it in the jails's fstab, I have to manually mount it after starting the jail. Otherwise X11 on the host ends up in some weird state where `xhost` says that it doesn't detect the display, I can't launch a new xterm, and attempting to reload my i3 config crashes X entirely. Everything behaves well though if I mount after jail startup, and I just now launched GUI programs from 2 separate jails simultaneously.
 
kpedersen said:
For my Jails I simply mv the /tmp/.X11-host into them. You can't copy a UNIX domain socket but you can move it (if it is on the same filesystem).

Did the nullfs mount work? I have always been interested but never got round to trying.

You probably don't want to mv the .X11-host file into them and back again to launch non-guest programs, so perhaps use Xephyr instead and move that socket into the jail for connection?
Click to expand...

I figured out why I was having problems with fstab, having to mount after jail start, and getting weird errors with X. I needed to put in the jail's rc.conf: clear_tmp_X="NO" . The nullfs mount was happening, and then the jail was trying to clear the X data, which is shared with host.
 
To continue this thread (even though I have the feeling few/no people will see it. The answer to my question is YES, there are security risks, and I just discovered one...

From inside of a GUI jail sharing /tmp/.X11-unix, I ran a screenshot tool, which had access to my entire X11 windows on the host. This of course shouldn't be surprising, but could totally be a security weakness if doing sensitive work. I have no doubt there are other weaknesses.

I may consider creating epairs and forwarding over some networking protocol, to prevent jails access to the rest of my windows,
 
BawdyAnarchist said:
From inside of a GUI jail sharing /tmp/.X11-unix, I ran a screenshot tool, which had access to my entire X11 windows on the host.
Click to expand...

You mentioned Qubes OS earlier.
This is the kind of thing Qubes is designed to prevent, and it does so by running on Xen.

Qubes dom0 is based on Fedora, and I'd like ZFS to be my base fs, so would like to use FreeBSD.

Running OSes with GUIs in Bhyve doesn't seem to be as easy as using Qubes.

Don't know if Bhyve has X11 crosstalk -- if it does, there's no point using it for this purpose.
(Security-wise, all I want is to separate internet banking from general web browsing.)

Haven't tried any of this, and my technical knowledge is limited -- just browsing for the general concepts so far.
 
j77h said:
You mentioned Qubes OS earlier.
This is the kind of thing Qubes is designed to prevent, and it does so by running on Xen.

Qubes dom0 is based on Fedora, and I'd like ZFS to be my base fs, so would like to use FreeBSD.

Running OSes with GUIs in Bhyve doesn't seem to be as easy as using Qubes.

Don't know if Bhyve has X11 crosstalk -- if it does, there's no point using it for this purpose.
(Security-wise, all I want is to separate internet banking from general web browsing.)

Haven't tried any of this, and my technical knowledge is limited -- just browsing for the general concepts so far.
Click to expand...

I'm almost certain that Qubes has modified Xorg code to segregate the GUI workspace between VMs while being simultaneously displayed on one screen. This is far beyond my level of competency. I'm pretty sure now that using bhyve VMs to segregate GUI (and then forwarding X11) would have precisely zero security benefits over multiple jails sharing .X11-unix socket.

Also, this means that the clipboard can be shared, which is again, another security risk, if you're using say, keepass for passwords/logins.

Also, interesting to note, the next major Qubes release will see a GUI VM, where they can further segregate the security risks of Xorg from dom0, and will also enable the usage of OpenCL / GL, which is one reason that running Qubes is often so damn difficult from an efficiency perspective. Right now, a Librem Qubes laptop is my secure compute environment, and FreeBSD is my desktop and tinkering environment.
 
You must log in or register to reply here.
Back
Top