Ubuntu has issued an advisory on February 12:
Patched packages uploaded for Mageia 3, Mageia 4, and Cauldron.
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).
Updated packages in core/updates_testing:
Steps to Reproduce:
Can you explain how to create an lxc container to test this issue?
[root@marley ~]# lxc-create -n foooo -t lxc-sshd
lxc-create: unknown template 'lxc-sshd'
[root@marley ~]# lxc-create -n foooo -t sshd
lxc-create: unknown template 'sshd'
[root@marley ~]# lxc-create -n foooo -t /usr/libexec/lxc/templates/lxc-sshd
lxc-create: unknown template '/usr/libexec/lxc/templates/lxc-sshd'
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.
Testing MGA4 64-bit
First, the actual change described and highlighted:
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
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.
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*
Binary file /usr/bin/lxc-execute matches
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.
MGA3TOO MGA4-64-OK =>
MGA3TOO feedback MGA4-64-OK
Adding some previous committers.
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:
MGA3TOO feedback MGA4-64-OK =>
Testing mga3 64
Still a no go I'm afraid.
# urpmf --media "Core Updates Testing" ^lxc: | grep templates
# lxc-create -n lxcsshd -t /usr/share/lxc/templates/lxc-sshd
lxc-create: unknown template '/usr/share/lxc/templates/lxc-sshd'
# lxc-create -n lxcsshd -t lxc-sshd
lxc-create: unknown template 'lxc-sshd'
# 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/
-rwxr-xr-x 1 root root 11624 Feb 24 20:27 lxc-init*
# rpm -q lxc
MGA3TOO MGA4-64-OK =>
MGA3TOO MGA4-64-OK feedback
Using Lewis process, update validated on Mageia 4 32
MGA3TOO MGA4-64-OK feedback =>
MGA3TOO MGA4-64-OK feedback MGA4-32-OK
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
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.
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..
(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..
Ouch! Is this true with the /release version and the update?
Difficult to test now :D
(In reply to claire robinson from comment #15)
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..
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.
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: