Ubuntu has issued an advisory on February 12: http://www.ubuntu.com/usn/usn-2104-1/ Patched packages uploaded for Mageia 3, Mageia 4, and Cauldron. Advisory: ======================== Updated lxc packages fix security vulnerability: Florian Sagar discovered that the LXC sshd template set incorrect mount permissions. An attacker could possibly use this flaw to cause privilege escalation on the host (CVE-2013-6441). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6441 http://www.ubuntu.com/usn/usn-2104-1/ ======================== Updated packages in core/updates_testing: ======================== lxc-0.8.0-1.1.mga3 liblxc0-0.8.0-1.1.mga3 liblxc-devel-0.8.0-1.1.mga3 lxc-0.9.0-5.1.mga4 liblxc0-0.9.0-5.1.mga4 liblxc-devel-0.9.0-5.1.mga4 from SRPMS: lxc-0.8.0-1.1.mga3.src.rpm lxc-0.9.0-5.1.mga4.src.rpm Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO
Can you explain how to create an lxc container to test this issue? I've tried: [root@marley ~]# lxc-create -n foooo -t lxc-sshd lxc-create: unknown template 'lxc-sshd' lxc-create: aborted [root@marley ~]# lxc-create -n foooo -t sshd lxc-create: unknown template 'sshd' lxc-create: aborted [root@marley ~]# lxc-create -n foooo -t /usr/libexec/lxc/templates/lxc-sshd lxc-create: unknown template '/usr/libexec/lxc/templates/lxc-sshd' lxc-create: aborted Note that all command previously complained: lxc-create: configuration path '/var/lib/lxc' not found until I mkdir'ed that folder. I guess I'm doing something wrong? It's a pretty trivial change however, so I'd have no problem suggesting it be pushed regardless of issue specific testing.
CC: (none) => mageia
Testing MGA4 64-bit lxc-0.9.0-5.1.mga4 lib64lxc0-0.9.0-5.1.mga4 First, the actual change described and highlighted: https://github.com/lxc/lxc/commit/f4d5cc8e1f39d132b61e110674528cac727ae0e2 I got over the problem in Comment 1 by citing the full template pathname 'but only discovered this *after* updating lxc). The relationship template-config file is not really mentioned at all in the extensive man lxc page. It seems you create a container config file citing a template. lxc-create -n lxcsshd -t /usr/share/lxc/templates/lxc-sshd lxc-create: No config file specified, using the default config /etc/lxc/default.conf Generating public/private rsa key pair ... Generating public/private dsa key pair. ... '/usr/share/lxc/templates/lxc-sshd' template installed 'lxcsshd' created And the important line in /usr/share/lxc/templates/lxc-sshd: lxc.mount.entry = /usr/share/lxc/templates/lxc-sshd sbin/init none ro,bind 0 0 of which the 'ro' mount attribute is what was changed [from nothing => rw I think]. So this looks OK.
CC: (none) => lewyssmithWhiteboard: MGA3TOO => MGA3TOO MGA4-64-OK
Testing mga3 32 Things are a bit different. It's a bit unfinished. Templates are stored in /usr/libexec/lxc/templates/ # ll /usr/libexec/lxc/templates/lxc-sshd -rwxr-xr-x 1 root root 5150 Apr 1 2013 /usr/libexec/lxc/templates/lxc-sshd* lxc-create fails with missing /var/lib/lxc which is the hard coded configuration path in the /usr/bin/lxc-create script, lxc_path, but not created/owned by any package. It seems to create directories there for the containers, at a glance. # grep /var/lib/lxc /usr/bin/lxc* /usr/bin/lxc-clone:lxc_path=/var/lib/lxc /usr/bin/lxc-create:lxc_path=/var/lib/lxc /usr/bin/lxc-destroy:lxc_path=/var/lib/lxc Binary file /usr/bin/lxc-execute matches /usr/bin/lxc-ls:lxc_path=/var/lib/lxc Binary file /usr/bin/lxc-restart matches /usr/bin/lxc-setcap: test -e /var/lib/lxc || mkdir -p /var/lib/lxc /usr/bin/lxc-setcap: chmod 0777 /var/lib/lxc /usr/bin/lxc-setcap: chmod 0755 /var/lib/lxc /usr/bin/lxc-setuid: test -e /var/lib/lxc || mkdir -p /var/lib/lxc /usr/bin/lxc-setuid: chmod 0777 /var/lib/lxc /usr/bin/lxc-setuid: chmod 0755 /var/lib/lxc Binary file /usr/bin/lxc-start matches Appears to need either lxc-setcap or lxc-setuid to be run before it can be used, which isn't documented anywhere, have no man pages and are really designed to allow usage by non root users. I think this directory should be created during installation. Adding 'feedback' for now.
Whiteboard: MGA3TOO MGA4-64-OK => MGA3TOO feedback MGA4-64-OK
Adding some previous committers.
CC: (none) => boklm, thierry.vignaud
I synced some changes that had been made to the package post-Mageia 3 (which mainly changes some of the directories that are used) and made sure the /var/lib/lxc directory gets installed with the main package. Mageia 3 updated packages are now: lxc-0.8.0-1.2.mga3 liblxc0-0.8.0-1.2.mga3 liblxc-devel-0.8.0-1.2.mga3 from lxc-0.8.0-1.2.mga3.src.rpm
Whiteboard: MGA3TOO feedback MGA4-64-OK => MGA3TOO MGA4-64-OK
Testing mga3 64 Still a no go I'm afraid. # urpmf --media "Core Updates Testing" ^lxc: | grep templates lxc:/usr/share/lxc/templates lxc:/usr/share/lxc/templates/lxc-altlinux lxc:/usr/share/lxc/templates/lxc-archlinux lxc:/usr/share/lxc/templates/lxc-busybox lxc:/usr/share/lxc/templates/lxc-debian lxc:/usr/share/lxc/templates/lxc-fedora lxc:/usr/share/lxc/templates/lxc-lenny lxc:/usr/share/lxc/templates/lxc-opensuse lxc:/usr/share/lxc/templates/lxc-sshd lxc:/usr/share/lxc/templates/lxc-ubuntu lxc:/usr/share/lxc/templates/lxc-ubuntu-cloud # lxc-create -n lxcsshd -t /usr/share/lxc/templates/lxc-sshd lxc-create: unknown template '/usr/share/lxc/templates/lxc-sshd' lxc-create: aborted # lxc-create -n lxcsshd -t lxc-sshd lxc-create: unknown template 'lxc-sshd' lxc-create: aborted # ll /usr/share/lxc/templates/lxc-sshd -rwxr-xr-x 1 root root 5153 Feb 24 20:27 /usr/share/lxc/templates/lxc-sshd* # ll /usr/libexec/lxc/ total 12 -rwxr-xr-x 1 root root 11624 Feb 24 20:27 lxc-init* # rpm -q lxc lxc-0.8.0-1.2.mga3
Whiteboard: MGA3TOO MGA4-64-OK => MGA3TOO MGA4-64-OK feedback
Using Lewis process, update validated on Mageia 4 32
CC: (none) => ennael1Whiteboard: MGA3TOO MGA4-64-OK feedback => MGA3TOO MGA4-64-OK feedback MGA4-32-OK
Whiteboard: MGA3TOO MGA4-64-OK feedback MGA4-32-OK => MGA3TOO has_procedure feedback MGA4-64-OK MGA4-32-OK
Hmm, well considering the SPEC changes I made, this should be the same in Mageia 3 now as Mageia 4. If it still isn't working, the software itself must be broken (it is an older version). I'm not sure what we can do about that.
OK, strace helped me figure this out. You have to run it as: lxc-create -n lxcsshd -t sshd
Whiteboard: MGA3TOO has_procedure feedback MGA4-64-OK MGA4-32-OK => MGA3TOO has_procedure MGA4-64-OK MGA4-32-OK
And on that note, testing complete for me on Mageia 3 i586 using Lewis's procedure.
Well done :) Testing mga3 64 now.
Whiteboard: MGA3TOO has_procedure MGA4-64-OK MGA4-32-OK => MGA3TOO has_procedure mga3-32-ok MGA4-64-OK MGA4-32-OK
Testing complete mga3 64 A word of caution for next time.. *DON'T* use lxc-destroy to try and remove the container you created, it starts to delete your / filesystem.. Oops.
(In reply to claire robinson from comment #12) > Testing complete mga3 64 > > A word of caution for next time.. > > *DON'T* use lxc-destroy to try and remove the container you created, it > starts to delete your / filesystem.. > > Oops. Ouch! Is this true with the /release version and the update?
Difficult to test now :D
https://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg04640.html
(In reply to claire robinson from comment #15) > https://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg04640.html I think that's just complaining that it deletes data at all, not that it deletes the *host* root filesystem. Something else is wrong here.
So lxc-destroy is just a shell script, the rm -rf command is the last line. The $lxc_path directory is defined correctly in the script at the top as /var/lib/lxc, so damage *should* be limited to underneath there, and the --one-file-system --preserve-root options it uses should prevent it from recursing into other mount points or deleting the root filesystem, so it's not obvious why it did that.
I interrupted it ctrl-c when it couldn't unmount stuff. I guess there is no error checking in the script so it happily rm -rf'd what was mounted.
If that is the case and it's configured to allow non root to use it is it possible that non root could destroy the root fs?
(In reply to claire robinson from comment #19) > If that is the case and it's configured to allow non root to use it is it > possible that non root could destroy the root fs? No, it's a shell script. It runs with the privileges of the user that executes it.
Adding the OK. I think the problem was driver error, but it's dangerous behaviour and makes it onto the QA sh1t list..
Whiteboard: MGA3TOO has_procedure mga3-32-ok MGA4-64-OK MGA4-32-OK => MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-64-OK MGA4-32-OK
Validating, advisory uploaded. Please push to 3 & 4 core/updates.
Keywords: (none) => validated_updateWhiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-64-OK MGA4-32-OK => MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-64-OK MGA4-32-OK advisoryCC: (none) => remi, sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGASA-2014-0102.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
CC: boklm => (none)