[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/
Re: [arch-general] Linux container
Op 12 feb. 2014 12:59 schreef "arnaud gaboury" het volgende: > > 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
Re: [arch-general] Linux container
> > 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.
Re: [arch-general] Linux container
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
Re: [arch-general] Linux container
On Wed, 12 Feb 2014 12:59:43 +0100 arnaud gaboury wrote: > 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 signature.asc Description: PGP signature
Re: [arch-general] Linux container
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
Re: [arch-general] Linux container
> You'll have to build a custom kernel. > ah... Another new step for me. fine, I learn, I learn.
Re: [arch-general] Linux container
> > 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.
Re: [arch-general] Linux container
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
Re: [arch-general] Linux container
> > 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 !
Re: [arch-general] Linux container
> > 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? --
Re: [arch-general] Linux container
On Thu, 13 Feb 2014 19:00:49 +0100 arnaud gaboury wrote: > > > > 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 signature.asc Description: PGP signature
[arch-general] Linux container with systemd-nspawn
Hi all, I run systemd-git I manage a arch container using systemd-nspawn facilities. I am still strugling with the tty story on the container. The container is running and $ machinectl status dahlia output is correct. This output thus puzzles me: gabx@hortensia ➤➤ systemd/system % sudo loginctl -M dahlia SESSIONUID USER SEAT 1 1000 gab seat0 c1 0 root seat0 c2 1000 gab seat0 c3 1000 gab seat0 c4 1000 gab seat0 c5 1000 gab seat0 c6 1000 gab seat0 c7 1000 gab seat0 c8 1000 gab seat0 Now reading machinectl man page, I shall be able to open a terminal session to the container. gabx@hortensia ➤➤ ~ # machinectl login dahlia Failed to start getty service: Unit container-getty@0.service failed to load: No such file or directory. On the host, I # cp /usr/lib/systemd/system/container-getty@.service to /etc/systemd/system/. I am not sure it is needed. >From the systemd mailing list : "systemd-getty-generator" will now look for $container_ttys set as an environment variable for PID 1. If that is set it will split the string up on whitespaces and start a getty on all ptys referenced. Note that this only supports ptys, not any other ttys. Example: "container_ttys=pts/5 pts/8 pts/15" and about systemd 209 : * If the $container_ttys environment variable is set, getty-generator will automatically spawn a getty for each listed tty. This is useful for container managers to request login gettys to be spawned on as many ttys as needed. Where shall I write such environment variable ? /etc/systemd/system.conf ? Is part of the job done inside the container (it is running systemd 208-11) ? Thank you for help
