This bug was fixed in the package lxc - 1.0.0~alpha1-0ubuntu13
---
lxc (1.0.0~alpha1-0ubuntu13) saucy-proposed; urgency=low
* debian/rules and debian/lxc.postinst: set /var/lib/lxc and /var/cache/lxc
to be perms 700. That prevents unprivileged users from running setuid-root
Confirmed on precise
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1244635
Title:
setuid executables in a container may compromise security on the host
To manage notifications about t
And confirmed on saucy. Marking verification-done.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1244635
Title:
s
This bug was fixed in the package lxc - 0.8.0~rc1-4ubuntu39.12.10.5
---
lxc (0.8.0~rc1-4ubuntu39.12.10.5) quantal-proposed; urgency=low
* add mkdir before chown of /var/{lib,cache}/lxc to avoid build
failure.
lxc (0.8.0~rc1-4ubuntu39.12.10.4) quantal-proposed; urgency=low
* debi
This bug was fixed in the package lxc - 0.9.0-0ubuntu3.7
---
lxc (0.9.0-0ubuntu3.7) raring-proposed; urgency=low
* debian/rules and debian/lxc.postinst: set /var/lib/lxc and /var/cache/lxc
to be perms 700. That prevents unprivileged users from running setuid-root
applicatio
This bug was fixed in the package lxc - 0.7.5-3ubuntu69
---
lxc (0.7.5-3ubuntu69) precise-proposed; urgency=low
* mkdir /var/{cache.lib}/lxc before chmoding them to avoid FTBFS.
lxc (0.7.5-3ubuntu68) precise-proposed; urgency=low
* debian/rules and debian/lxc.postinst: set /var/
Confirmed on quantal
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1244635
Title:
setuid executables in a container may compromise security on the host
To manage notifications about t
Confirmed on raring
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1244635
Title:
setuid executables in a container may compromise security on the host
To manage notifications about th
Hello Andrea, or anyone else affected,
Accepted lxc into saucy-proposed. The package will build now and be
available at
http://launchpad.net/ubuntu/+source/lxc/1.0.0~alpha1-0ubuntu13 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wik
The saucy fix must wait for another active SRU to complete.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1244635
Title:
setuid executables in a container may compromise security on th
Waiting for the SRU to land in Saucy. Has it been delayed for some
reason or has it been forgotten? :-)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1244635
Title:
setuid executables
Not to mention the change is being SRUed to all release, so they'll get
the change way before they dist-upgrade.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1244635
Title:
setuid exe
Quoting Seth Arnold (1244...@bugs.launchpad.net):
> Serge, what does " After this version, respect the user's choice." mean?
It means if the user manually chmods /var/lib/lxc to 755, we don't
change it again after this. (Except, see below)
> Does this mean someone upgrading from e.g. 12.04.3 lxc
Serge, what does " After this version, respect the user's choice." mean?
Does this mean someone upgrading from e.g. 12.04.3 lxc packages to 14.04
lxc packages -- skipping this update -- would have the 'unsafe'
permissions?
Or will this check be carried before to e.g. 14.04 lxc packages and only
ex
Hello Andrea, or anyone else affected,
Accepted lxc into precise-proposed. The package will build now and be
available at http://launchpad.net/ubuntu/+source/lxc/0.7.5-3ubuntu68 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubu
** Changed in: lxc (Ubuntu Quantal)
Status: New => Fix Committed
** Changed in: lxc (Ubuntu Raring)
Status: New => Fix Committed
** Changed in: lxc (Ubuntu Raring)
Importance: Undecided => Medium
** Changed in: lxc (Ubuntu Quantal)
Importance: Undecided => Medium
** Changed
This bug was fixed in the package lxc - 1.0.0~alpha2-0ubuntu5
---
lxc (1.0.0~alpha2-0ubuntu5) trusty; urgency=low
[ Serge Hallyn]
* debian/rules and debian/lxc.postinst: set /var/lib/lxc and /var/cache/lxc
to be perms 700. That prevents unprivileged users from running setuid-
** Also affects: lxc (Ubuntu Quantal)
Importance: Undecided
Status: New
** Description changed:
+ ==
+ 1. Impact: unprivileged users could run setuid-root binaries from out-of-date
containers.
+ 2. Development fix: make /var/lib/lxc world- and group-unre
Good news.
However I must say that the documentation on LXC does not say that
libvirt is less secure than the official LXC:
https://help.ubuntu.com/13.10/serverguide/lxc.html#lxc-libvirt
So either libvirt should ship with an Apparmor profile for LXC, or a
warning should be added to the relevant p
Right, libvirt-lxc isn't LXC (even though they sort of stole the name)
and is indeed completely unsafe...
As for the rest, I'm happy to report that you misread the apparmor profile and
that we thought of and blocked all of those from the beginning as is shown
below:
root@lxc-dev:/# echo abc > /s
Hi Stéphane,
I can see at least three ways of escaping.
The first is using LXC through libvirt. I see that there's an Apparmor
profile for usr.bin.lxc-start, but AFAIK libvirt does not use lxc-start.
Also, libvirt does not load the "lxc-containers" profile (AFAIK).
This is proven by the fact tha
For those users, getting back to the old way would be a chmod away and I
asked Serge to make sure permissions would only be changed once and not
with every update, so it should be a one time thing.
As for security, while we don't currently say LXC is secure on Ubuntu,
we're not aware of any way to
> I also don't feel that this is a high priority bug since, so far, we
do not recommend allowing unprivileged users to use containers.
Agreed. Especially because (currently) it's fairly easy to escape from
LXC when you have root access to the container.
> I don't believe it would be a serious los
Thanks for pointing this out. I don't believe it would be a serious
loss of functionality to chmod 0700 /var/lib/lxc. I also don't feel
that this is a high priority bug since, so far, we do not recommend
allowing unprivileged users to use containers. So I think a regular
update in trusty with SR
24 matches
Mail list logo
