[SOLVED] general question: container isolation-level
Linux - ContainersThis forum is for the discussion of all topics relating to Linux containers. Docker, LXC, LXD, runC, containerd, CoreOS, Kubernetes, Mesos, rkt, and all other Linux container platforms are welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
Last edited by sundialsvcs; 02-14-2018 at 07:32 AM.
But, I think, you trust these processes not to be malicious. They're in a container, and they're not trying to get out
So "trusted" processes (= "normal" ones which I also had no problem in running outside a container or sandbox) are O.K.
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?
So "trusted" processes (= "normal" ones which I also had no problem in running outside a container or sandbox) are O.K.
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?
You may want to run even "trusted" processes in an LXD container, so that they do not mess up with your host (adding repositories, packages and dependencies).
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.
tnx again.
Your link makes for interesting reading. Thereīs still much for me to learn....
Quote:
Between LXD and firejail, the latter needs from you to make the correct configuration (profile).
Yes, thatīs often a bit of a hassle.
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.
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.
It sure does. Tnx a lot for that.
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.
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
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
** Note: you can use --noprofile to disable default.profile **
Parent pid 10157, child pid 10158
Child process initialized in 6984.77 ms
Init...
XRandRWait: No value set. Using default.
XRandRWait: Started by user.
Checking setup...
Launching TeamViewer ...
Starting network process (no daemon)
terminate called without an active exception
/opt/teamviewer/tv_bin/script/tvw_exec: Zeile 95: 116 Abgebrochen "$TV_BIN_DIR/teamviewerd" -n -f
Network process already started (or error)
Launching TeamViewer GUI ...
Parent is shutting down, bye...
Team-viewer itself presents a GUI-based text message:
Quote:
"teamviewer daemon not running.
Please start daemon before using TeamViewer (needs root):
----------teamviewer --daemon start ----------
[...]"
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.
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.
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.
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.
But as I said Iīll give it try.
As soon as I have (or havenīt any) results Iīll post them here.
Hi Rosika,
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.
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.
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:
Init...
*** TeamViewer can not be executed with sudo! ***
Either use your normal user account without sudo
or use a the real root account to log in to your desktop (not recommended!).
chown: changing ownership of '/home/ubuntu/alte_version_teamviewer/teamviewer/logfiles/startup.log': Op
eration not permitted
I logged in my container by using the command lxc exec guiapps -- sudo --login --user ubuntu, as you recommended in your tutorial.
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:
lxc console guiapps
doesnīt work with me. I get the error:
Quote:
error: unknown command: console
Itīs a bit of a shame that I cannot get teamviewer running. Could you suggest some way to get this done?
A containerized process should live in its own happy, isolated, world, and should be in every way confined to it.
Thatīs a valid point.
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.
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.
[...] it will look like the user ubuntu logged in.
O.K., I understand.
But if the user ubuntu is logged in that means "normal user", right?
So I fail to understand why I get
Quote:
*** TeamViewer can not be executed with sudo! ***
Either use your normal user account without sudo
or use a the real root account to log in to your desktop (not recommended!).
I logged in my container by using the command lxc exec guiapps -- sudo --login --user ubuntu, as you recommended in your tutorial.
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?
doesnīt work with me. I get the error:
Itīs a bit of a shame that I cannot get teamviewer running. Could you suggest some way to get this done?
Hi Rosika,
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.
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,
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.
and then run
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
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.
