7

Is it possible to use LXC on a desktop system to confine browsers and other pieces of software that have in the past been shown to be prone to certain kinds of exploits. So what I want to achieve is to jail, say Firefox, be still able to view its windows etc and yet be sure it only has read and write access to anything "inside the bubble", but not the host system.

The example lxc-sshd container in LXC suggests something like this should be possible (app-level containers), but I have only seen this for program that require a TTY at most.

Can this work also under KDE, GNOME, Unity ...?

0xC0000022L
  • 16,593
  • 5
    Not the same technology, but note that there's a SELinux policy in Fedora to contain Firedox in exactly this way. – mattdm Sep 25 '13 at 03:44
  • https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ – 0xC0000022L May 11 '14 at 18:58
  • Also, an honorable mention of apparmor: It, too, can limit what an application has access to and it comes with many pre-configured ready-to-use profiles for various applications (including firefox). – Hermann Apr 06 '20 at 05:56

4 Answers4

5

Firejail is a Linux namespaces sandbox program that can jail Firefox or any other GUI software. It should work on any Linux computer.

netblue
  • 126
2

Not directly. With technologies such as LXC or OpenVZ the applications inside them are essentially there own Linux boxes. So you'll need to do it "remotely" using tools such as X2go or VNC to see their remote desktops, or remotely display applications running inside them using X.

There is this tutorial which discusses how to do this using Debian/Ubuntu, but much of the steps should be translatable to other distros as well. The article is titled: Debian Virtualization: LXC Desktop Virtualization.

slm
  • 369,824
  • LXC does not have to be configured for 100% isolation. – psusi Sep 25 '13 at 02:00
  • @psusi - OK, can you add how to do that to your answer? I'd be curious to see how, not doubting you, just curious 8-) – slm Sep 25 '13 at 02:02
  • No, since I haven't actually done it. I just know that they added a bunch of features to the kernel for lxc to be able to share mount points between the containers and what gui apps need access to in order to display. – psusi Sep 25 '13 at 02:07
  • @psusi - can you point me to references so I can read up on it then? – slm Sep 25 '13 at 02:10
  • @slm From http://unix.stackexchange.com/questions/92177/kernel-namespaces-support : http://lwn.net/Articles/524952/ will get you started. – Gilles 'SO- stop being evil' Sep 25 '13 at 04:35
  • @Gilles - just happen to have this...you kill me.. – slm Sep 25 '13 at 04:53
2

What desktop manager you are running does not matter; all that matters is that you provide the container with access to the Xwindows socket, the XAUTHORITY environment variable, and the file it points to.

psusi
  • 17,303
  • Could you give the relevant pieces from the configuration which would get me started?! Thanks. – 0xC0000022L Sep 25 '13 at 04:55
  • If your GUI App (e.g. firefox) can talk to Xwindows via socket, then there's quite a big window for exploiting bugs in X to escape the container to whatever X can access. So the question becomes whether you can put X windows inside a container. – mc0e Nov 21 '14 at 08:09
1

An lxc container does not have a display/audio of its own, so it must somehow use the host display/audio. A typical linux solution would be either of

  1. share host X resources directly across the container boundary
  2. use X forwarding over an ssh reverse pipe

The problem with either of those solutions is that something evil on the container might take control via X to view windows or capture key strokes, etc. X was not designed with that kind of security in mind.

Another solution would be to use what might be called a masquerade X server, which is not really an X server but presents an pseudo X interface and a pseudo X screen to the client software on the container, while passing some X work off to the real X server behind it. The psuedo X screen is displayed as a single X window on the host actual X desktop.

One such masquerade X server is the software Xephyr in the xserver-xephyr which was actually developed for X developers debugging.

I wrote a simple javascript program to create (from a vanilla ubuntu lxc image) an lxd/lxc container populated with firefox, openvpn, Xephyr , and pulseaudio. Target host is also Ubuntu. VPN forwards all the ip traffic to a VPS.

https://github.com/craigphicks/browser-on-lxc-vpn-xephyr

https://www.npmjs.com/package/browser-on-lxc-vpn-xephyr

Ultimately, when considering vulnerability from Specter et. al., even a container offers no guarantee - a separate physical CPU is required to achieve theoretical perfect defense. (The actual degree of threat is arguable - no wild exploits have been reported a year on). As a solution it would be easy enough to put a container on another machine.

That might protect the host machine (or might not - I make no promise). However, usually the browser is used for entering lots of sensitive information - passwords and OTPs. SIP and social distancing is the best security but it's not a great lifestyle.

Craig Hicks
  • 664
  • 1
    There's no perfect security, but there are different mitigations for different risks. That's why one usually does a risk analysis. For me the most relevant scenario is the typical ransomware scenario. So something that gets in via the browser and basically encrypts user files. By placing the whole thing into a namespaced browser, I hope to achieve a separation that the browser alone doesn't give me. Thanks for your input. – 0xC0000022L Apr 06 '20 at 09:05
  • So you are using firejail - that looks pretty interesting! – Craig Hicks Apr 06 '20 at 09:26