<div dir="ltr">><span style="font-size:12.8px">The use case that we have in mind is to allow an unprivileged user run a preconfigured container, which configuration is only writable for power users. Ideally the unprivileged user should not be able to meddle with the cgroups or even create new containers.</span><br><br><span style="font-size:12.8px">How I handle this is that my web application. It accepts user input (sanitization + validation) then creates a container on the host machine. The container is equipped with a LAMP stack with sshd running and new keys generated. The user of the container can ssh into their container and meddle away. They can take snap shots before they meddle. I don't really care. I care about if the user can break out of the container. And as long as the kernel is secure, they can't.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">j</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 16, 2017 at 8:59 PM, Dr. Todor Dimitrov <span dir="ltr"><<a href="mailto:dimitrov@technology.de" target="_blank">dimitrov@technology.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I guess LXD would not be an option since we are talking about resource constrained devices. The unprivileged user is actually used only for namespacing purposes and not for actual logins. The power user starts a “provisioning/bootstrapping" process as the unprivileged user, which in turn starts the lxc container and performs some additional tasks, e.g. monitoring. The bootstrapping process might not be “trusted” in the sense that it could have bugs, which should not have any adverse effects on the main functionality of the device.</div><div><br></div><div>Maybe the problem can be re-formulated: is an unprivileged container owned by an unprivileged user any more safer than an unprivileged container owned by root?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Todor</div><div><br></div></font></span><div><blockquote type="cite"><div><div class="h5"><div>On 17. May 2017, at 01:38, Fajar A. Nugraha <<a href="mailto:list@fajar.net" target="_blank">list@fajar.net</a>> wrote:</div><br class="m_1534865228373835925Apple-interchange-newline"></div></div><div><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 16, 2017 at 12:21 PM, Dr. Todor Dimitrov <span dir="ltr"><<a href="mailto:dimitrov@technology.de" target="_blank">dimitrov@technology.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>My understanding is that the unprivileged user owning the container can still alter the cgroups, right?</div><div><br></div></div></blockquote><div><br></div><div><br></div><div>You should really try lxd. e.g. <a href="https://linuxcontainers.org/lxd/try-it/" target="_blank">https://linuxcontainers.<wbr>org/lxd/try-it/</a> , or install it on your own ubuntu server/vm.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>The use case that we have in mind is to allow an unprivileged user run a preconfigured container, which configuration is only writable for power users. Ideally the unprivileged user should not be able to meddle with the cgroups or even create new containers.</div><div><br></div><div>Is such a scenario feasible to implement using LXC and cgroups?</div></div></blockquote><div><br></div><div><br></div><div>That's what lxd does. Sort of. Some options:</div><div>- you create an unpriv container (the default in lxd), then give access to the container (e.g. ssh keys, root pass of the container, etc) to the user. They will be able to restart the container and install whetever package they want, but they can't create another container</div><div><br></div><div>- you create an unpriv container with nesting enabled (which is what the try-me link does). The unpriv user will have a set of limits (e.g. total disk space, total memory, etc) which they can use to create containers under it.</div><div><br></div><div>In either way, the container's root user will not be able to alter it's own cgroup configuration (e.g. /sys/fs/cgroup/memory/<wbr>memory.limit_in_bytes). </div><div><br></div><div>-- </div><div>Fajar</div></div></div></div></div></div><span class="">
______________________________<wbr>_________________<br>lxc-users mailing list<br><a href="mailto:lxc-users@lists.linuxcontainers.org" target="_blank">lxc-users@lists.<wbr>linuxcontainers.org</a><br><a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.<wbr>org/listinfo/lxc-users</a></span></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
lxc-users mailing list<br>
<a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.<wbr>linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users" rel="noreferrer" target="_blank">http://lists.linuxcontainers.<wbr>org/listinfo/lxc-users</a><br></blockquote></div><br></div>