[lxc-users] iptables-persistent not loading rules

[Eric W. Biederman]

Serge Hallyn <serge.hallyn at ubuntu.com> writes:

> Quoting Sergey (sergeyn at gmail.com):
>> Hi,
>> 
>> Is your container unprivileged?
>> I'm experiencing the same issue with unprivileged container on ubuntu
>> trusty.
>> 
>> I've tried to investigate it with strace. There is the log:
>> 
>> # strace iptables-save 2>&1 |tail
>> > mprotect(0x7fdd75e12000, 4096, PROT_READ) = 0
>> > mprotect(0x7fdd76019000, 4096, PROT_READ) = 0
>> > mprotect(0x613000, 4096, PROT_READ)     = 0
>> > mprotect(0x7fdd7623d000, 4096, PROT_READ) = 0
>> > munmap(0x7fdd76238000, 11652)           = 0
>> > brk(0)                                  = 0x7cc000
>> > brk(0x7ed000)                           = 0x7ed000
>> > open("/proc/net/ip_tables_names", O_RDONLY|O_CLOEXEC) = -1 EACCES
>> > (Permission denied)
>> > exit_group(0)                           = ?
>> > +++ exited with 0 +++
>> >
>> 
>> # ls  -l /proc/net/ip_tables_names
>> > -r--r----- 1 nobody nogroup 0 Nov 24 15:12 /proc/net/ip_tables_names
>> >
>> 
>> It looks like access permissions are the main issue.
>
> Yeah, looking at the file on the host it is root-owned, and not
> world readable.
>
> Each unpriv container gets its own l2 stack, but I'm not sure whether
> the list of ip tables is also different per container.  If it is, then
> I think this may be just an oversight, and the file could be set to
> be owned by uid 0 in the user_ns owning the /proc/net.  Otherwise,
> such a change would likely be a security issue.
>
> I'm cc:ing Eric as he might know offhand.

This sounds like an oversight.  I don't recall changing the ownership of
any of the files when I vetted the networking stack for safety.

I don't think it would be too hard to implement, just a proc_set_user
call in an appropriate location.   But I took a quick look and there
is only one proc_set_user call in the networking stack and it isn't to
the file ip_tables_names.

Eric