Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?
Hello Fajar, > Anyway, I wrote this several months ago, should be the easiest way to > get unpriv jessie on jessie: http://debian-lxc.github.io/ > The repo has lxc-1.1.5 and cgmanager, ported from ubuntu. I just discover your link and I wonder how I could miss it! Thanks a lot, it seems that everything is well explained. I will test your tutorials soon ;-) Xavier ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?
On Sat, Jan 9, 2016 at 3:40 AM, Xavier Gendre wrote: > Hello Carlos, > >> Once you replace systemd with sysvinit in the container, you get it >> booting and starting the services, but you can't login on it (via the >> login prompt) or ssh on it. > > I didn't know that, i always use lxc-attach to get a prompt in my > containers and it works like a charm. > >> You will get the following error: >> >> " Cannot make/remove an entry for the specified session " >> >> This is caused because Debian now requires pam_loginuid for both login >> an sshd >> >> # grep pam_loginuid /etc/pam.d/* >> /etc/pam.d/login:sessionrequired pam_loginuid.so >> /etc/pam.d/sshd:sessionrequired pam_loginuid.so >> >> You have to remove that line from both files to be able to login on the >> container via the login prompt or via ssh > > Thanks for that point, i will use it one day if i need to properly login > or ssh into one of my containers. Hmmm ... I wonder why this old thread is suddenly active again. Anyway, I wrote this several months ago, should be the easiest way to get unpriv jessie on jessie: http://debian-lxc.github.io/ The repo has lxc-1.1.5 and cgmanager, ported from ubuntu. You can choose between a custom cgroup (like what you suggested in eariler mail), or have systemd create it automatically with a ported ubuntu's version of systemd (also available in the repo). It also address ssh login issue (by comenting out the pam_loginuid line above) and root-inside-container-path issue (by using "lxc-attach -n CONTAINER_NAME -- sudo -i") -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?
Hello Carlos, > Once you replace systemd with sysvinit in the container, you get it > booting and starting the services, but you can't login on it (via the > login prompt) or ssh on it. I didn't know that, i always use lxc-attach to get a prompt in my containers and it works like a charm. > You will get the following error: > > " Cannot make/remove an entry for the specified session " > > This is caused because Debian now requires pam_loginuid for both login > an sshd > > # grep pam_loginuid /etc/pam.d/* > /etc/pam.d/login:sessionrequired pam_loginuid.so > /etc/pam.d/sshd:sessionrequired pam_loginuid.so > > You have to remove that line from both files to be able to login on the > container via the login prompt or via ssh Thanks for that point, i will use it one day if i need to properly login or ssh into one of my containers. Xavier ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] cgmanager buffer overflow
Hi, Are there crashfiles under /var/crash? if so you should be able to open a bug with the apport-retrace info using apport-bug /var/crash/thefile or you can debug yourself using apport-retrace -g /var/crash/thefile -serge ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Status: Debian Jessie support for unprivileged containers?
On 13/10/15 12:11, Xavier Gendre wrote: > > You can run unprivileged Jessie container in a Jessie host. The point is > that the container fails to start mainly because of systemd in the > Jessie container. > > To tackle that problem, i create a custom image of Jessie without > systemd and it runs perfectly. I give the details to create the image > and the container in my blog (in french, sorry): > > https://www.meseira.fr/blog/post/2015/08/02/unprivileged-jessie-container/ Is not that simple. Once you replace systemd with sysvinit in the container, you get it booting and starting the services, but you can't login on it (via the login prompt) or ssh on it. You will get the following error: " Cannot make/remove an entry for the specified session " This is caused because Debian now requires pam_loginuid for both login an sshd # grep pam_loginuid /etc/pam.d/* /etc/pam.d/login:sessionrequired pam_loginuid.so /etc/pam.d/sshd:sessionrequired pam_loginuid.so You have to remove that line from both files to be able to login on the container via the login prompt or via ssh More info: http://gaijin-nippon.blogspot.com.es/2013/07/audit-on-lxc-host.html https://www.pld-linux.org/docs/lxc#loginuid https://github.com/lxc/lxc/issues/661 signature.asc Description: OpenPGP digital signature ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] is starting unprivileged containers as root as secure as running them as any other user?
Quoting Carlos Alberto Lopez Perez (clo...@igalia.com): > Hi, > > > Suppose that we create an unprivileged container as root (using the > download template or manually converting it with uidmapshift). > > Such container config will contain (for example) the following maps: > > lxc.id_map = u 0 10 65536 > lxc.id_map = g 0 10 65536 > > And root would be also allowed to use them: > > $ usermod --add-subuids 10-165536 root > $ usermod --add-subgids 10-165536 root > > > My question is > > From a security point of view, does creating and starting an > unprivileged container as root make any difference than doing it as any > other user of the host? Yes. For example, if you'll then be running lxc-attach as root instead of as an unpriv user, then any attacks from inside the container against lxc-attach will attack the root user. > My understanding is that once the unprivileged container is running, > root inside such container won't be able to get a host_uid < 10 (in > this example) so starting the unprivileged container as root will be as > secure as starting the container as any other user that is allowed to do > so via the subuid/subgid maps. Is this right? > > Thanks. > > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] cgmanager buffer overflow
Sorry, forgot to mention that the host is running Ubuntu 15.10, the lxc version is 1.1.5-0ubuntu0.15.10.3, and the container is running Ubuntu 15.10. On Thu, Jan 7, 2016 at 12:01 PM, Shimin Guo wrote: > Saw the following in syslog from a machine in our CI cluster. It's causing > all kinds of problems for our application. I can't reproduce it reliably, > but our test suite, which brings up and tears down containers many times > during its course, triggers this problem pretty much every time. > Unfortunately since we use EC2, the machine is long gone, and I don't have > much beyond the contents of /var/log/. Can someone derive some hint from > this log as to what is going on? > > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: *** buffer overflow > detected ***: /sbin/cgmanager terminated > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: === Backtrace: > = > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: > /lib/x86_64-linux-gnu/libc.so.6(+0x78c4e)[0x7f29189b1c4e] > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f2918a51e8c] > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: > /lib/x86_64-linux-gnu/libc.so.6(+0x116e80)[0x7f2918a4fe80] > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: > /lib/x86_64-linux-gnu/libc.so.6(+0x118dd7)[0x7f2918a51dd7] > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: > /lib/x86_64-linux-gnu/libnih.so.1(nih_io_select_fds+0xd0)[0x7f2919162970] > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: > /lib/x86_64-linux-gnu/libnih.so.1(nih_main_loop+0x109)[0x7f2919166f79] > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: > /sbin/cgmanager(+0x5145)[0x562e317f4145] > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f2918959a40] > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: > /sbin/cgmanager(+0x53d9)[0x562e317f43d9] > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: === Memory map: > > > Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: 562e317ef000-562e31811000 > r-xp ca:01 12884 /sbin/cgmanager > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 562e31a11000-562e31a13000 > r--p 00022000 ca:01 12884 /sbin/cgmanager > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 562e31a13000-562e31a14000 > rw-p 00024000 ca:01 12884 /sbin/cgmanager > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 562e339e7000-562e34426000 > rw-p 00:00 0 [heap] > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29171a5000-7f29171bb000 > r-xp ca:01 395872 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29171bb000-7f29173ba000 > ---p 00016000 ca:01 395872 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29173ba000-7f29173bb000 > r--p 00015000 ca:01 395872 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29173bb000-7f29173bc000 > rw-p 00016000 ca:01 395872 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29173bc000-7f29173c8000 > r-xp ca:01 403839 /lib/x86_64-linux-gnu/ > libnss_files-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29173c8000-7f29175c7000 > ---p c000 ca:01 403839 /lib/x86_64-linux-gnu/ > libnss_files-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29175c7000-7f29175c8000 > r--p b000 ca:01 403839 /lib/x86_64-linux-gnu/ > libnss_files-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29175c8000-7f29175c9000 > rw-p c000 ca:01 403839 /lib/x86_64-linux-gnu/ > libnss_files-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29175c9000-7f29175d4000 > r-xp ca:01 403823 /lib/x86_64-linux-gnu/ > libnss_nis-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29175d4000-7f29177d3000 > ---p b000 ca:01 403823 /lib/x86_64-linux-gnu/ > libnss_nis-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29177d3000-7f29177d4000 > r--p a000 ca:01 403823 /lib/x86_64-linux-gnu/ > libnss_nis-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29177d4000-7f29177d5000 > rw-p b000 ca:01 403823 /lib/x86_64-linux-gnu/ > libnss_nis-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29177d5000-7f29177ec000 > r-xp ca:01 403845 /lib/x86_64-linux-gnu/ > libnsl-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29177ec000-7f29179eb000 > ---p 00017000 ca:01 403845 /lib/x86_64-linux-gnu/ > libnsl-2.21.so > > Jan 7 06:59:33 ip-10-97-235-172
[lxc-users] cgmanager buffer overflow
Saw the following in syslog from a machine in our CI cluster. It's causing all kinds of problems for our application. I can't reproduce it reliably, but our test suite, which brings up and tears down containers many times during its course, triggers this problem pretty much every time. Unfortunately since we use EC2, the machine is long gone, and I don't have much beyond the contents of /var/log/. Can someone derive some hint from this log as to what is going on? Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: *** buffer overflow detected ***: /sbin/cgmanager terminated Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: === Backtrace: = Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: /lib/x86_64-linux-gnu/libc.so.6(+0x78c4e)[0x7f29189b1c4e] Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f2918a51e8c] Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: /lib/x86_64-linux-gnu/libc.so.6(+0x116e80)[0x7f2918a4fe80] Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: /lib/x86_64-linux-gnu/libc.so.6(+0x118dd7)[0x7f2918a51dd7] Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: /lib/x86_64-linux-gnu/libnih.so.1(nih_io_select_fds+0xd0)[0x7f2919162970] Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: /lib/x86_64-linux-gnu/libnih.so.1(nih_main_loop+0x109)[0x7f2919166f79] Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: /sbin/cgmanager(+0x5145)[0x562e317f4145] Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f2918959a40] Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: /sbin/cgmanager(+0x53d9)[0x562e317f43d9] Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: === Memory map: Jan 7 06:59:32 ip-10-97-235-172 cgmanager[801]: 562e317ef000-562e31811000 r-xp ca:01 12884 /sbin/cgmanager Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 562e31a11000-562e31a13000 r--p 00022000 ca:01 12884 /sbin/cgmanager Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 562e31a13000-562e31a14000 rw-p 00024000 ca:01 12884 /sbin/cgmanager Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 562e339e7000-562e34426000 rw-p 00:00 0 [heap] Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29171a5000-7f29171bb000 r-xp ca:01 395872 /lib/x86_64-linux-gnu/libgcc_s.so.1 Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29171bb000-7f29173ba000 ---p 00016000 ca:01 395872 /lib/x86_64-linux-gnu/libgcc_s.so.1 Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29173ba000-7f29173bb000 r--p 00015000 ca:01 395872 /lib/x86_64-linux-gnu/libgcc_s.so.1 Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29173bb000-7f29173bc000 rw-p 00016000 ca:01 395872 /lib/x86_64-linux-gnu/libgcc_s.so.1 Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29173bc000-7f29173c8000 r-xp ca:01 403839 /lib/x86_64-linux-gnu/ libnss_files-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29173c8000-7f29175c7000 ---p c000 ca:01 403839 /lib/x86_64-linux-gnu/ libnss_files-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29175c7000-7f29175c8000 r--p b000 ca:01 403839 /lib/x86_64-linux-gnu/ libnss_files-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29175c8000-7f29175c9000 rw-p c000 ca:01 403839 /lib/x86_64-linux-gnu/ libnss_files-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29175c9000-7f29175d4000 r-xp ca:01 403823 /lib/x86_64-linux-gnu/ libnss_nis-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29175d4000-7f29177d3000 ---p b000 ca:01 403823 /lib/x86_64-linux-gnu/ libnss_nis-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29177d3000-7f29177d4000 r--p a000 ca:01 403823 /lib/x86_64-linux-gnu/ libnss_nis-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29177d4000-7f29177d5000 rw-p b000 ca:01 403823 /lib/x86_64-linux-gnu/ libnss_nis-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29177d5000-7f29177ec000 r-xp ca:01 403845 /lib/x86_64-linux-gnu/ libnsl-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29177ec000-7f29179eb000 ---p 00017000 ca:01 403845 /lib/x86_64-linux-gnu/ libnsl-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29179eb000-7f29179ec000 r--p 00016000 ca:01 403845 /lib/x86_64-linux-gnu/ libnsl-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29179ec000-7f29179ed000 rw-p 00017000 ca:01 403845 /lib/x86_64-linux-gnu/ libnsl-2.21.so Jan 7 06:59:33 ip-10-97-235-172 cgmanager[801]: 7f29179ed000-7f29179ef000 rw-p 00:00 0 Jan 7 06:59:
[lxc-users] is starting unprivileged containers as root as secure as running them as any other user?
Hi, Suppose that we create an unprivileged container as root (using the download template or manually converting it with uidmapshift). Such container config will contain (for example) the following maps: lxc.id_map = u 0 10 65536 lxc.id_map = g 0 10 65536 And root would be also allowed to use them: $ usermod --add-subuids 10-165536 root $ usermod --add-subgids 10-165536 root My question is From a security point of view, does creating and starting an unprivileged container as root make any difference than doing it as any other user of the host? My understanding is that once the unprivileged container is running, root inside such container won't be able to get a host_uid < 10 (in this example) so starting the unprivileged container as root will be as secure as starting the container as any other user that is allowed to do so via the subuid/subgid maps. Is this right? Thanks. signature.asc Description: OpenPGP digital signature ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unable to use LXD >= 0.25 on LVM storage backend
Micky Del Favero writes: > Probably I'm doing something wrong, but I'm not able to identify what, > with LXD 0.24 I've no problem at all (even if my hack, see next mail). Yesterday I investigate a bit and solve the issue, it's sufficient to set: auto_set_activation_skip = 0 in lvm.conf. See https://github.com/lxc/lxd/issues/1470 for details. Ciao, Micky -- The sysadmin has all the answers, expecially "No" ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] apparmor kernel log entries
> Von: lxc-users [mailto:lxc-users-boun...@lists.linuxcontainers.org] Im > > Quoting Fiedler Roman (roman.fied...@ait.ac.at): > > > Von: lxc-users [mailto:lxc-users-boun...@lists.linuxcontainers.org] Im > > > Auftrag von Serge Hallyn > > > > > > Wait - are you saying you want tasks in the container to be able to > > > ptrace tasks on the host? > > > > Yes, is possible. Sounds like > > I'm asking whether he *wants* the tasks to be able to do that. Well, not knowing his exact setup, question might be if he wants the machine to want it. With an adversary on it already, it would be the the best way to hide the ptrace-exploit within a top/ps instance (thus hide also true positive failed exploitation attempt messages from auditd within false-positive ptrace-attach messages when accessing proc file system, making it easier to come to same FP-conclusion on a TP), best using a rouge shared library from tempfs with ld-preload (thus not really leaving traces on the disk), and as a whole, thus being hard to distinguish from real admin activity using only really trivial tricks. > If not, then apparmor is correctly stopping the exploit. If so, then I'd > be interested in the use case. Yes, if he did not modify apparmor and has the appropriate lxc-updates from last year in place mitigating the apparmor-escape exploits. smime.p7s Description: S/MIME cryptographic signature ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
