To my way of thinking, containers are – as I said – an illusion that's especially intended to isolate processes on the inside of the container from correctly perceiving the world outside of it. (And, to prevent them from consuming more than their allotted share of resources.) But, I think, you trust these processes not to be malicious. They're in a container, and they're not trying to get out.
Since the whole thing is basically a bunch of kernel configuration parameters, with a certain group of processes running with that same set of parameters (that "container") in effect, there is really no overhead. And that's the point. Although virtual machines also rely upon hardware assistance, there's a lot more overhead associated with them. If you don't actually need what only a VM can do, containers are a compelling alternative that can serve ordinary isolation requirements very efficiently. The fact that they are "ordinary processes running directly on a Linux kernel," even though they're wearing funny glasses and a straitjacket, can also work to your advantage because they can be more easily interacted with from the outside. |
Hi sundialsvcs,
Quote:
Thus better not try running any funny things in containers. I understand. But (only theoretically): would running them in VMs or firejail provide a higher degree of protection for the host? Rosika |
Quote:
For example, if there is a Nodejs app that you need to run, better put it in a container. Then, you can remove the container and any trace of it is gone. See, for example, https://blog.simos.info/how-to-insta...lxd-container/ Between LXD and firejail, the latter needs from you to make the correct configuration (profile). If you make the configuration very restrictive, the process may crash. If you relax the security, it may be too open and miss required restrictions. There are no known vulnerabilities in the default configuration of LXD. If something appears down the line, it will get fixed quickly. |
Hi simosx,
tnx again. Your link makes for interesting reading. Thereīs still much for me to learn.... Quote:
Iīve been using firejail for quite a while now and have learned the hard way that itīs not always working the desired way. I do not want to be misunderstood: For most applications it works just fine. And there are a lot of profiles (https://github.com/netblue30/firejail/tree/master/etc). Yet thereīs still a vmplayer.profile missing (though thereīs one for VirtualBox). And I havenīt succeeded in creating the correct configuration for it yet. So your point is very valid. Greetings. Rosika |
Hi Rosika,
Let's add a bit more. I hope the discussion remains interesting. Apart from LXD and firejail, there are also the snap packages that are based on Linux security features. I would say that firejail is closer to snap packages than to LXD. With snap packages, an application is described in a configuration file called snapcraft.yaml, and then it is built (from source) into a snap package. Then, you may upload this snap package to the Ubuntu Store so anyone can make use of it. Snap packages are supported in many major distributions. Here is the firejail configuration for darktable, https://github.com/netblue30/firejai...ktable.profile Here is the snapcraft.yaml configuration for darktable, https://github.com/kyrofa/darktable-...snapcraft.yaml My quick viewing shows me that these are almost equivalent. To make a proper comparison, compare to the plugs section in snapcraft.yaml (which interfaces are allowed). To install darktable as a snap, you would run Code:
snap install darktable |
Hi simosx,
Quote:
Iīve heard about snap. Yet itīs not installed by default on my Lubuntu. So it was never really on my mind. The only thing I knew was that itīs some kind of packet format in order to be used alongside the normal packet management. What I didnīt know is that it has security mechanisms implemented. So Iīll look into that. Yor links are helpful. :study: My interest in container-technology stems from the fact that I wanted to get teamviewer running in a sandbox (firejail). Up and until now it is the only programm that I use that doesnīt work within firejail. So Iī m looking for alternatives to get teamviewer going in a secure environment. And thus containers came to my mind. Greetings. Rosika P.S.: If you are interested why teamviewer doesnīt work within firejail: Terminal-output: Code:
rosika@rosika-Lenovo-H520e ~> firejail teamviewer Quote:
But no solution so far. |
Hi Rosika,
I tried as well to get Teamviewer in a LXD container according to the guide at https://blog.simos.info/how-to-run-g...buntu-desktop/ It did not work in the beginning but now it almost works. It works locally only and cannot get a connection to the Teamviewer servers. I am mystified as to why it cannot connect with the Teamviewer servers even if the LXD container has Internet connectivity. I assume Teamviewer carries lots of baggage that makes it behave weirdly on non-standard systems. Here is how it works in a LXD container. 1. Set up a LXD container according to https://blog.simos.info/how-to-run-g...buntu-desktop/ 2. Connect to the LXD container with Code:
$ lxc console guiapps 3. Run teamviewer Code:
ubuntu@guiapps:~$ teamviewer I did not try all other network connectivity options (use proxy, etc). On another note, I put online an index of my LXD tutorials, https://discuss.linuxcontainers.org/...-of-simos/1228 |
Hi Simos,
thanks for your reply. I couldnīt answer yesterday because the linuxquestions-server was down for a while. O.K., Iīll do the following: Accordning to your guide for runnng GUI-apps in LCD-containers Iīm going to try to get team-viewer running. But I doubt that Iīll be more successful than you. Because... why should I? Youīre the professional here. :hattip: But as I said Iīll give it try. As soon as I have (or havenīt any) results Iīll post them here. Thanks also for the index of your LXD-tutorials. Very impressive. Greetings. Rosika |
Quote:
I gave it a try again and I have come up to the following: TeamViewer works in Linux over LXD, as long as you do not use the latest Teamviewer 13. TeamViewer 13 is based on Qt, and is a departure from the older versions that use Wine. Using Qt by itself should not be an issue. I did the easy task and tried out TeamViewer versions 10, 11 and 12. All from https://www.teamviewer.com/en/downlo...ious-versions/ And they just worked. I simply got the TAR files, extracted them and ran TeamViewer. I hope I can figure out why TeamViewer 13 does not work on LXD. edit: here is a guide, https://blog.simos.info/how-to-run-teamviewer-in-lxd/ |
:scratch: At the moment, the only thing I associate with "trusted container" is the question of whether-or-not the container occupant, when it attempts to "become 'root,'" actually does so on the host machine.
And, as far as I'm concerned, no container should ever be so "trusted." A containerized process should live in its own happy, isolated, world, and should be in every way confined to it. If something needs to be done "to" the actual host environment, IMHO it should only be done "in" that environment. |
Hi simosx,
tnx a lot for your reply. Sorry for the belated answer. Alas I couldnīt get teamviewer running. I proceeded as follows: According to your very well-written guide I got my lxd-container running. I also named it "guiapps". That went well. Then I installed teamviewer. Yet it was version 13. After reading your latest post I uninstalled it and got the "v11.0.67687"-version from https://www.teamviewer.com/en/downlo...ious-versions/. That as o.k. as well. But as with version 13 I get an error-message when trying to start it: ubuntu@guiapps:~/alte_version_teamviewer/teamviewer$ ./teamviewer Quote:
Yet Iīm not quite sure as to what the "sudo"-command does. Am I logged in with sudo? Might that be the cause of denial? Quote:
Quote:
Greetings. Rosika |
Hi sundialsvcs,
tnx for your comment. Quote:
So the thing is: How could one prevent processes within the container to become "root"? If I understand you correctly containerization wouldnīt be the way to go for running untrusted proccesses in an isolated environment. Greetings. Rosika |
sudo --login --user ubuntu
means: set user as ubuntu, simulate a login. So finally when you start the container it will look like the user ubuntu logged in. The container initially started as root. |
Hi pan64,
tnx for the explanation. Quote:
But if the user ubuntu is logged in that means "normal user", right? So I fail to understand why I get Quote:
Greetings. Rosika |
Quote:
Thanks for going through the tutorial! I tried to get TeamViewer to work with LXD several times before (those times were unsuccessful). During the tests, I have come up with the opinion that the source of TeamViewer contains a lot of legacy code that makes it behave weirdly. One of those weird behaviors is exactly the example you are giving. Other weird behaviors were complaining that world-readable files were not readable. As I write in https://blog.simos.info/how-to-run-teamviewer-in-lxd/ there are three common ways to connect to your LXD container,
TeamViewer is so weird that lxc exec is not good enough to run it. You must use lxc console instead. lxc console is a new command to LXD, therefore if you have Ubuntu 16.04 you would get a somewhat older (but fully supported until 2021) version of LXD. There are two ways to upgrade to the latest LXD, One way is to install the snap version of LXD according to the instructions at https://blog.simos.info/how-to-migra...-snap-package/ The other way is to install LXD from the backports repository. To do so, enable the backports repository in Software & Updates (software-properties-gtk). Click to tick the highlighted line that says xenial-backports. https://i.imgur.com/rSrUMFt.png and then run Code:
sudo apt install lxd=2.21-0ubuntu3~17.10.1 lxd-client=2.21-0ubuntu3~17.10.1 |
All times are GMT -5. The time now is 02:16 AM. |