[lxc-users] Owner of an unprivileged container
Hello, I run several containers on my server and, following the security advices, they are unprivileged. Each container belongs to one user and I am asking myself if this is a good practice... Thus my question is if there are some differences between: - an unprivileged container owned by root with 'lxc.id_map' in its config file to make it unprivileged, - a similar unprivileged container but owned by a classical user. From the practical point of view, I have to admit that a container owned by root is easier to handle but, from the security point of view, is it more safe to give the unprivileged container to an user than to root? Or is the namespace sufficient to avoid escape from an unprivileged container that belongs to root? What are your good practices in the matter? All belong to root? All belong to one devoted user? Or, as what I do, one user for one container? Thanks, Xavier ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] live migration using lxd 0.4
Hi KATOH,
On Thu, Mar 26, 2015 at 04:52:17PM +0900, KATOH Yasufumi wrote:
On Tue, 24 Mar 2015 08:34:36 -0600
in message Re: [lxc-users] live migration using lxd 0.4
Tycho Andersen-san wrote:
Sorry about that. This was a bug that I inadvertently introduce just
before 0.4 was released. It is fixed by
141734d852b9ffb34eca10366e96d57c93ff23e8, which went in shortly after
0.4 was tagged, and will be in 0.5 due to be released today.
Thank you for your reply! I'm trying to do live migration using 0.5
now :-) But I have not succeeded yet. (^^;)
I'm working on getting everything working again with privileged LXC
(several recent changes have broken things), once that happens the LXD
bits are in place to make it will be easy to do migration in LXD.
| 2015/03/26 16:41:59 operation %!s(func()
| shared.OperationResult=0x4c5d20) finished: { checkpoint failed}
You'll also find that you need some other stuff to do live migration
(not documented anywhere, unfortunately):
1. you can't use lxcfs (or any other fuse fs)
I stopped lxcfs.
2. only non-uidmapped containers work (you can do this in lxd by just
setting the uidmap for lxd to be 0-65536, or by setting the uidmap
in the container's raw.lxc config)
I have a question. What does non-uidmapped container means? Should I
configure security.privileged true? Would you please tell me the way
to configure it specifically?
I just tried to do this, and it appears to be broken. I sent a PR to
fix it,
https://github.com/lxc/lxd/pull/438
So you'll need that as well as an LXC built with my two recent c/r
patches to the lxc-devel list (which haven't been merged yet). If you
have all that, I think you can do something like
lxc profile create migratable
lxc profile edit migratable
# paste the content below; these are a bunch of fixes for current criu
# limitations.
name: migratable
config:
raw.lxc: |
lxc.console = none
lxc.cgroup.devices.deny = c 5:1 rwm
lxc.start.auto =
lxc.start.auto = proc:mixed sys:mixed
security.privileged: true
devices: {}
Then do:
# assuming lxd2 is your target remote
lxc profile copy migratable lxd2:
lxc init ubuntu migratee
lxc config profile apply migratee migratable
lxc start migratee
# assuming lxd2 is the http:// url for your default lxd
lxc move lxd:migratee lxd2:migratee
And you should see it try to migrate. Currently it will still fail because of
external bind mounts like binfmt and some others. I'm working on a patch for
this now, but you could disable the additional bind mounts if you're not using
them and it should work.
Tycho
3. you can't be using systemd on the host
I use busybox and ubuntu container. :)
4. probably some others that I've forgotten about at the moment :)
Thanks for trying the code though! I'll hopefully be sending out fixes
for some of this stuff in the coming weeks. Let me know if you have
any problems and I can try and give you workarounds.
Tycho
Thanks,
KATOH Yasufumi
___
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
[lxc-users] Building LXC 1.1 on Debian 8
I've been using LXC's on Debian 7 for over a year now and everything has been working great, but I've just been using the version that is packaged with the distro and I figured it's probably time to get up to date and start taking advantage of the newer features and unprivileged containers. So I've created a VM with Debian 8 on it and downloaded the source for LXC 1.1.1. I configured, compiled, and installed the software without any issues, but when I try to run lxc-create as a regular user I get the following error: -- lxcuser@thinkhost:~$ lxc-create -t download -n c1 unshare: Operation not permitted read pipe: Success lxc_container: lxccontainer.c: do_create_container_dir: 772 Failed to chown container dir lxc_container: lxc_create.c: main: 274 Error creating container c2 -- I've set execute rights on the home directory for that user. Seems like I'm missing something obvious. Below is the configure parameters I used. make, make check, and make install reported no problems or errors: ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-doc --enable-capabilities --with-distro=debian I can run the above command as root and it successfully downloads the template and creates the container which I can then attach to. Thanks, Joshua ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] live migration using lxd 0.4
On Tue, 24 Mar 2015 08:34:36 -0600
in message Re: [lxc-users] live migration using lxd 0.4
Tycho Andersen-san wrote:
Sorry about that. This was a bug that I inadvertently introduce just
before 0.4 was released. It is fixed by
141734d852b9ffb34eca10366e96d57c93ff23e8, which went in shortly after
0.4 was tagged, and will be in 0.5 due to be released today.
Thank you for your reply! I'm trying to do live migration using 0.5
now :-) But I have not succeeded yet. (^^;)
| 2015/03/26 16:41:59 operation %!s(func()
| shared.OperationResult=0x4c5d20) finished: { checkpoint failed}
You'll also find that you need some other stuff to do live migration
(not documented anywhere, unfortunately):
1. you can't use lxcfs (or any other fuse fs)
I stopped lxcfs.
2. only non-uidmapped containers work (you can do this in lxd by just
setting the uidmap for lxd to be 0-65536, or by setting the uidmap
in the container's raw.lxc config)
I have a question. What does non-uidmapped container means? Should I
configure security.privileged true? Would you please tell me the way
to configure it specifically?
3. you can't be using systemd on the host
I use busybox and ubuntu container. :)
4. probably some others that I've forgotten about at the moment :)
Thanks for trying the code though! I'll hopefully be sending out fixes
for some of this stuff in the coming weeks. Let me know if you have
any problems and I can try and give you workarounds.
Tycho
Thanks,
KATOH Yasufumi
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
