[arch-general] Linux container
Dear all, I am slowly building a Arch Linux VM guest on my Arch Linux host. The guest machine is now built and is recognized as shown by this command : gabx@hortensia ➤➤ ~ % machinectl list MACHINE CONTAINER SERVICE dahlia container nspawn 1 machines listed. I an following the libvirt.org documentation. Now, according this page[1] about lxc driver, i am dealing with namespace requirements. This sentence, in bold, puzzles me: A suitably configured UID/GID mapping is a pre-requisite to making containers secure, in the absence of sVirt confinement. If I understand what a namespace is, I have no idea how to make sure my UIG/GID mapping is well configured. I would appreciate having any hints abut this part of the settings. Another question : is there any advantage/disadvantage using the lxc Userspace tools[2] instead of libvirt to manage these namespaces ? Thank you for help. [1]http://libvirt.org/drvlxc.html [2]http://linuxcontainers.org/
Op 12 feb. 2014 12:59 schreef "arnaud gaboury"
Dear all,
I am slowly building a Arch Linux VM guest on my Arch Linux host.
The guest machine is now built
[...]
I an following the libvirt.org documentation. Now, according this page[1] about lxc driver, i am dealing with namespace requirements. This sentence, in bold, puzzles me:
A suitably configured UID/GID mapping is a pre-requisite to making containers secure, in the absence of sVirt confinement.
If I understand what a namespace is, I have no idea how to make sure my UIG/GID mapping is well configured. I would appreciate having any hints abut this part of the settings.
That means is that you need to make sure that the users on the host and the guest machine should have the same UID (usernumber) and GID(GroupNumber). The point is that you now have 2 "computers" that can access the same data. If you set access to certain files using different usernames, but identical (numeric) UID's, the "wrong" people could be able to access those files. Other then what one would think based on the displayed user- and groupnames. It would also make troubleshooting trickier. If you can keep the used numbers in sync between both installations, then every user/group permission means the same in both environments. mvg, Guus
That means is that you need to make sure that the users on the host and the guest machine should have the same UID (usernumber) and GID(GroupNumber).
The point is that you now have 2 "computers" that can access the same data. If you set access to certain files using different usernames, but identical (numeric) UID's, the "wrong" people could be able to access those files. Other then what one would think based on the displayed user- and groupnames. It would also make troubleshooting trickier.
If you can keep the used numbers in sync between both installations, then every user/group permission means the same in both environments.
mvg, Guus
TY Guus for your answer. I think I understand the overall principle. The trick is I have no idea how setup all this stuff in a concrete manner. A basic example would help me.
Am Mi 12 Feb 2014 18:44:11 CET schrieb arnaud gaboury:
That means is that you need to make sure that the users on the host and the guest machine should have the same UID (usernumber) and GID(GroupNumber).
The point is that you now have 2 "computers" that can access the same data. If you set access to certain files using different usernames, but identical (numeric) UID's, the "wrong" people could be able to access those files. Other then what one would think based on the displayed user- and groupnames. It would also make troubleshooting trickier.
If you can keep the used numbers in sync between both installations, then every user/group permission means the same in both environments.
mvg, Guus
TY Guus for your answer. I think I understand the overall principle. The trick is I have no idea how setup all this stuff in a concrete manner. A basic example would help me.
To secure your container you have to make sure that the users in the container will be represented as different ids to the host system. Especially root in the container must not have root access to the host. Here is some more reading material for you: http://libvirt.org/drvlxc.html#secureusers http://libvirt.org/formatdomain.html#elementsOSContainer
On 12/02/2014 20:06, ProgAndy wrote:
To secure your container you have to make sure that the users in the container will be represented as different ids to the host system. Especially root in the container must not have root access to the host. Here is some more reading material for you: http://libvirt.org/drvlxc.html#secureusers http://libvirt.org/formatdomain.html#elementsOSContainer
The (kernel) feature discussed here is the user namespace. It enables cointainers to have a different uid/guid mapping than the one on the host. This should be a safe way to allow root users inside containers whitout giving them full access on the host at the same time. This feature is relatively new and is not enabled in the default Arch Linux kernel: $ zgrep USER_NS /proc/config.gz # CONFIG_USER_NS is not set You'll have to build a custom kernel. -- Timothée Ravier
On Wednesday 12 Feb 2014 21:00:54 arnaud gaboury wrote:
You'll have to build a custom kernel.
ah... Another new step for me. fine, I learn, I learn.
That's what makes ArchLinux so awesome: once you're done, your understanding will be greatly expanded. As you move from project to project, the curve flattens out, you find it easier to understand how everything is fitting together, and you suddenly discover that you've landed in the territory that most others consider "expert" :) Paul
That's what makes ArchLinux so awesome: once you're done, your understanding will be greatly expanded. As you move from project to project, the curve flattens out, you find it easier to understand how everything is fitting together, and you suddenly discover that you've landed in the territory that most others consider "expert" :)
Paul
I totally agree Paul. I started a few days ago by building a simple VM with QEMU/libvirt, and I will finish with a Linux container and a custom Kernel !
This feature is relatively new and is not enabled in the default Arch Linux kernel: $ zgrep USER_NS /proc/config.gz # CONFIG_USER_NS is not set
You'll have to build a custom kernel.
-- Timothée Ravier
now I rebuilt the kernel with user space set. Shall I do another new install for the container with this new kernel? Or keep the container installed with the "old" kernel? --
On Thu, 13 Feb 2014 19:00:49 +0100
arnaud gaboury
This feature is relatively new and is not enabled in the default Arch Linux kernel: $ zgrep USER_NS /proc/config.gz # CONFIG_USER_NS is not set
You'll have to build a custom kernel.
-- Timothée Ravier
now I rebuilt the kernel with user space set. Shall I do another new install for the container with this new kernel? Or keep the container installed with the "old" kernel?
Probably not. The only thing you need to change is config, but you'd better check libvirt docs. By the way, there was a reason why usens was disabled in our kernel (FS#36969)... Cheers, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Wed, 12 Feb 2014 12:59:43 +0100
arnaud gaboury
Dear all,
I am slowly building a Arch Linux VM guest on my Arch Linux host.
The guest machine is now built and is recognized as shown by this command :
gabx@hortensia ➤➤ ~ % machinectl list MACHINE CONTAINER SERVICE dahlia container nspawn
1 machines listed.
I an following the libvirt.org documentation. Now, according this page[1] about lxc driver, i am dealing with namespace requirements. This sentence, in bold, puzzles me:
A suitably configured UID/GID mapping is a pre-requisite to making containers secure, in the absence of sVirt confinement.
If I understand what a namespace is, I have no idea how to make sure my UIG/GID mapping is well configured. I would appreciate having any hints abut this part of the settings.
User namespaces are currently disabled in the -ARCH kernel, so you should either build your own kernel, or do not configure any mapping (it is optional).
Another question : is there any advantage/disadvantage using the lxc Userspace tools[2] instead of libvirt to manage these namespaces ?
Namespaces are property of the kernel, not a userspace tool, so both are equivalent. Having said that, I prefer lxc tools because they are somewhat more flexible and come with fewer dependencies. Also notice, that if you don't need an advanced network configuration, systemd-nspawn may be sufficient for your purposes.
Thank you for help.
[1]http://libvirt.org/drvlxc.html [2]http://linuxcontainers.org/
-- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Also notice, that if you don't need an advanced network configuration, systemd-nspawn may be sufficient for your purposes.
I already played with systemd-nspawn, and it works good. Honestly, I have no idea if I shall stay on the libvirt-lxc side, or go systemd, or even both ?? The network setup will be quite tricky, as this VM is the test server for a later production server, with lots of web apps, domain name, secure connections etc etc.
participants (6)
-
arnaud gaboury
-
Guus Snijders
-
Leonid Isaev
-
Paul Gideon Dann
-
ProgAndy
-
Timothée Ravier