[lxc-users] sysctl -p no longer allowed in container

Dan Kegel dank at kegel.com
Fri Dec 11 05:20:04 UTC 2015


Came back to this because it hit me again (14.04 host, 15.10 guest this time).
I actually don't need to be able to write to /proc/sys/kernel/sem
from inside the container; I just need its limits to be high enough.

$ uname -a
Linux dank-desktop 3.13.0-66-generic #108-Ubuntu SMP Wed Oct 7
15:20:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ apt-cache policy lxc
lxc:
  Installed: 1.1.5-0ubuntu3~ubuntu14.04.1

Looks like at one point, inside was going to inherit from outside:
http://lists.linuxfoundation.org/pipermail/containers/2014-May/034544.html
but that doesn't seem to be happening here:

$ cat /proc/sys/kernel/sem
250 65536 32 32768
$ sudo lxc-start -n foo
$ ssh foo
$ cat /proc/sys/kernel/sem
250 32000 32 128

:-(

Is there a safe way to set the guest's /proc/sys/kernel/sem, either
from inside or from outside?
Pretend I don't know anything (which is pretty close to true at this point).

Thanks,
Dan

On Tue, Sep 22, 2015 at 8:45 AM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> Check /proc/self/mountinfo.
>
> /proc/self/mounts actually also shows the truth.  I don't know why
> 'mount' is lying.
>
> As for it being ro, I do see this as a step down.  If you look
> at /etc/apparmor.d/abstractions/lxc/container-base you see the
> lengths the policy went to to allow writes only to the sysctls
> which are safely namespaced (including /proc/sys/kernel/sem
> but not any other file/dir beginning with that name).  Doing
> this with mounts would be too much.
>
> If you use proc:rw you'll be allowed to do the write, but if
> you're not using apparmor (and the default policy) then the
> host will be vulnerable to sysctl resets from the container.
>
> -serge
>
> Quoting Dan Kegel (dank at kegel.com):
>> Alas, I just ran into this again on a 14.04 system
>> with lxc 1.1.3-0ubuntu1~ubuntu14.04.1~ppa1
>>
>> # echo 250 65536 32 32768 > /proc/sys/kernel/sem
>> bash: /proc/sys/kernel/sem: Read-only file system
>> # mount | grep proc
>> proc on /proc type proc (rw,noexec,nosuid,nodev)
>> proc on /proc/sys/net type proc (rw,noexec,nosuid,nodev,relatime)
>> proc on /proc/sys type proc (rw,noexec,nosuid,nodev,relatime)
>> ...
>>
>> What's going on there?
>>
>> - Dan
>>
>>
>> On Mon, Jun 9, 2014 at 3:56 PM, Stéphane Graber <stgraber at ubuntu.com> wrote:
>> > On Mon, Jun 09, 2014 at 10:53:01PM +0000, Serge Hallyn wrote:
>> >> Hi Stéphane,
>> >>
>> >> will commit 773bd28258371ad0058ff946c5cf94419920ffdd be in 1.0.4?
>> >
>> > Yes, it's currently in stable-1.0 and so will be included in 1.0.4.
>> >
>> >>
>> >> -serge
>> >>
>> >> Quoting Dan Kegel (dank at kegel.com):
>> >> > I guess this is in your daily ppa builds, but hasn't been released yet,
>> >> > as I just updated my system from beta trusty to release,
>> >> > and this bit me again.  Will the fix be in ubuntu 14.04.1?
>> >> >
>> >> > On Tue, Apr 29, 2014 at 2:41 PM, Dan Kegel <dank at kegel.com> wrote:
>> >> > > The patch you sent seems to let the container set kernel.sem,
>> >> > > and my build is back to green, thanks.
>> >> > >
>> >> > > You should probably ignore the problem in the outer system for now -
>> >> > > If I run into it again on a clean machine I'll post again.
>> >> > > - Dan
>> >> > >
>> >> > >
>> >> > > On Tue, Apr 29, 2014 at 2:20 PM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
>> >> > >> Quoting Dan Kegel (dank at kegel.com):
>> >> > >>> This may be a jinxed machine.  I installed it from trusty beta 2.  I
>> >> > >>> should probably try again with the released version.
>> >> > >>>
>> >> > >>> Inside the container:
>> >> > >>>
>> >> > >>> /proc/self/attr/current says lxc-container-default (enforce)
>> >> > >>> There's no line in syslog, and I don't have an audit/audit.log.
>> >> > >>> strace shows
>> >> > >>> open("/proc/sys/kernel/sem", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCESS
>> >> > >>
>> >> > >> Those make sense,
>> >> > >>
>> >> > >>> apt-cache policy apparmor says it's not installed.
>> >> > >>> Installing it says it won't start inside a container.
>> >> > >>>
>> >> > >>> And all this in spite of the container having apparmor off, and being able to
>> >> > >>
>> >> > >> Are you sure?  In what way did you turn it off?  Because it is
>> >> > >> definately on.
>> >> > >>
>> >> > >>> happily write to it there.
>> >> > >>>
>> >> > >>> I haven't been able to set that parameter in the container yet today :-(
>> >> > >>>
>> >> > >>> /var/log/upstart/procps.log in the container also shows
>> >> > >>>   sysctl: permission denied on key 'kernel.sem'
>> >> > >>> (since I put that setting into /etc/sysctl.conf)
>> >> > >>>
>> >> > >>> And apparmor_status inside lxc fails with permission denied on
>> >> > >>> /sys/kernel/security/apparmor/profiles
>> >> > >>> (which doesn't seem too surprising, but what do I know...)
>> >> > >>
>> >> > >> Right, but in the last email you said that you also could not
>> >> > >> set the sysctl from the host, not inside a container.  That's
>> >> > >> the one that worries me.  Can you show the same things for a
>> >> > >> root shell on the host?
>> >> > >> _______________________________________________
>> >> > >> lxc-users mailing list
>> >> > >> lxc-users at lists.linuxcontainers.org
>> >> > >> http://lists.linuxcontainers.org/listinfo/lxc-users
>> >> > _______________________________________________
>> >> > lxc-users mailing list
>> >> > lxc-users at lists.linuxcontainers.org
>> >> > http://lists.linuxcontainers.org/listinfo/lxc-users
>> >
>> > --
>> > Stéphane Graber
>> > Ubuntu developer
>> > http://www.ubuntu.com
>> >
>> > _______________________________________________
>> > lxc-users mailing list
>> > lxc-users at lists.linuxcontainers.org
>> > http://lists.linuxcontainers.org/listinfo/lxc-users
>> _______________________________________________
>> lxc-users mailing list
>> lxc-users at lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users


More information about the lxc-users mailing list