<div dir="ltr">This email is timely as I was researching this (again) last night. It resulted in me taking a look through the lxd demo server code and configs which I think do a very reasonable job at allowing untrusted users access to containers.<br><br><a href="https://github.com/lxc/lxd-demo-server">https://github.com/lxc/lxd-demo-server</a><br><div><br></div><div>My final thought was that if the community felt there was a bit more to add, we/I could fork the project and call it lxd-demo-server-paranoid with some extra security configuration primitives sprinkled on top.<br><br>I haven't defined what the "extras" would be, but if the idea sounds reasonable, I'd love some ideas.<br><br>Jared</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 9, 2017 at 8:22 AM, T.C 吳天健 <span dir="ltr"><<a href="mailto:tcwu2005@gmail.com" target="_blank">tcwu2005@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi , <div><br></div><div>Its said privileged container is unsecured . For example, if a user in the container (suppose it's running a service toward the public) hack the system with some kind of root kit. </div><div><br></div><div>I am thinking of building a more secure container.  The first idea is to use unprivileged container;  Second is apply cgroup to limit viewing of some sensitive /dev files, and any recommendation?</div><div><br></div><div>Summary</div><div>-use unprivileged container</div><div>-cgroup to limit viewing of some /dev files</div><div><br></div><div><br></div></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>