Quoting jeetu.gol...@gmail.com (jeetu.gol...@gmail.com):
> Hi Fajar,
> 
> Thanks again for taking the time to reply :)
> 
> I'm using Debian testing with lxc version 0.8.0~rc1-4. It's possible
> I'm using an outdated version of lxc.
> 
> > In Ubuntu host at least, AFAIK using lxc templates will include
> > network configuration from /etc/lxc/lxc.conf, which includes these
> > lines
> 
> I just verified and on my system I don't have a lxc.conf file. I'm not
> sure if I have to manually create this.

Right, just create one yourself, i.e.

cat > lxc.conf << EOF
lxc.network.type = phys                                                         
                                                                                
       
lxc.network.link = eth0                                                         
                                                                                
       
EOF

and then add '-f lxc.conf' to the lxc-create arguments.

> The default config template I have when I run a lxc-create -n test1 -t
> debian is as follows:
> 
> lxc.tty = 4

Note you can of course just add the network lines to this file by
yourself, you don't have to create a whole new container right now  :)

> lxc.pts = 1024
> lxc.rootfs = /var/lib/lxc/test1/rootfs
> lxc.cgroup.devices.deny = a
> # /dev/null and zero
> lxc.cgroup.devices.allow = c 1:3 rwm
> lxc.cgroup.devices.allow = c 1:5 rwm
> # consoles
> lxc.cgroup.devices.allow = c 5:1 rwm
> lxc.cgroup.devices.allow = c 5:0 rwm
> lxc.cgroup.devices.allow = c 4:0 rwm
> lxc.cgroup.devices.allow = c 4:1 rwm
> # /dev/{,u}random
> lxc.cgroup.devices.allow = c 1:9 rwm
> lxc.cgroup.devices.allow = c 1:8 rwm
> lxc.cgroup.devices.allow = c 136:* rwm
> lxc.cgroup.devices.allow = c 5:2 rwm
> # rtc
> lxc.cgroup.devices.allow = c 254:0 rwm
> 
> # mounts point
> lxc.mount.entry=proc /var/lib/lxc/test1/rootfs/proc proc nodev,noexec,nosuid 
> 0 0
> lxc.mount.entry=devpts /var/lib/lxc/test1/rootfs/dev/pts devpts defaults 0 0
> lxc.mount.entry=sysfs /var/lib/lxc/test1/rootfs/sys sysfs defaults  0 0
> 
> 
> I'm not sure of the specifics in the config file however my first
> reaction to lxc.cgroup.devices.deny = a was to assume that this would
> deny all devices just as you have mentioned. However this hasn't
> isolated the network instance in my case.
> 
> Anything in the above config seems out of ordinary? Or is it just that
> I'm using an outdated lxc? Of course it's entirely possible that I

No, the automatic use of a system lxc.conf is just an ubuntu thing.  Can't
really go upstream because it's pretty distro-specific.

> haven't rtfm ;) ;) - sorry if that's the case :)
> 
> Thanks again for everything guys :)
> 
> Bye for now
> 
> 
> 
> 
> On Tue, May 15, 2012 at 10:13 AM, Fajar A. Nugraha <l...@fajar.net> wrote:
> > On Tue, May 15, 2012 at 10:22 AM, jeetu.gol...@gmail.com
> > <jeetu.gol...@gmail.com> wrote:
> >> Hi Fajar,
> >>
> >> Thanks for your response.
> >>
> >> I used the debian template and the config file does not (as far as I
> >> can tell) have any network related stanzas. Unfortunately this default
> >> behaviour lead to the network stack being shared between the host and
> >> the container as pointed out by Matthijs.
> >
> > In Ubuntu host at least, AFAIK using lxc templates will include
> > network configuration from /etc/lxc/lxc.conf, which includes these
> > lines
> >
> > lxc.network.type=veth
> > lxc.network.link=lxcbr0
> > lxc.network.flags=up
> >
> >>
> >> Therefore, I was wondering if there are any other namespaces I should
> >> explicitly isolate so as to prevent them being inadvertently shared
> >> between host and container.
> >
> > Again, the resulting config file provides a good starting point. On
> > ubuntu precise host, using ubuntu template denies ALL devices (which
> > should include host's eth) from the guest container except from ones
> > specifically allowed
> >
> > #==========
> > lxc.cgroup.devices.deny = a
> > # Allow any mknod (but not using the node)
> > lxc.cgroup.devices.allow = c *:* m
> > lxc.cgroup.devices.allow = b *:* m
> > # /dev/null and zero
> > lxc.cgroup.devices.allow = c 1:3 rwm
> > lxc.cgroup.devices.allow = c 1:5 rwm
> > # consoles
> > lxc.cgroup.devices.allow = c 5:1 rwm
> > lxc.cgroup.devices.allow = c 5:0 rwm
> > #lxc.cgroup.devices.allow = c 4:0 rwm
> > #lxc.cgroup.devices.allow = c 4:1 rwm
> > # /dev/{,u}random
> > lxc.cgroup.devices.allow = c 1:9 rwm
> > lxc.cgroup.devices.allow = c 1:8 rwm
> > lxc.cgroup.devices.allow = c 136:* rwm
> > lxc.cgroup.devices.allow = c 5:2 rwm
> > # rtc
> > lxc.cgroup.devices.allow = c 254:0 rwm
> > #fuse
> > lxc.cgroup.devices.allow = c 10:229 rwm
> > #tun
> > lxc.cgroup.devices.allow = c 10:200 rwm
> > #full
> > lxc.cgroup.devices.allow = c 1:7 rwm
> > #hpet
> > lxc.cgroup.devices.allow = c 10:228 rwm
> > #kvm
> > lxc.cgroup.devices.allow = c 10:232 rwm
> > #==================
> >
> > --
> > Fajar
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Lxc-users mailing list
> Lxc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Reply via email to