[lxc-users] LXC and Unprivileged containers - purpose and status - talks

Mon Aug 17 08:17:50 UTC 2015

I've read somewhere:
"Ubuntu is also one of the few (if not only) Linux distributions to come
by default with everything that's needed for safe, unprivileged LXC
containers" - and not LTS versions.

El 17/08/15 a les 06:48, Benoit GEORGELIN - Association Web4all ha escrit:
> Hi lxc-users :) 
> 
> I'm currently working and playing around with LXC containers. I came
> across "Unprivileged Containers" 
> I would like to get some feedback about this really interesting feature. 
> It's not easy to get a good tour about the technology and about the
> maturity of this kind of containers.  First because I'm not technical
> enough to understand the differences between LXC and OpenVZ (besides
> Cgroups and kernels needs) , second because I'm not able to find
> documentation, talks or paper about it. 
> I'm here to talk about it, try to merge information from you guys and
> eventually make something public that can be shared to everyone having
> the same questions :) 
> 
> As I'm looking at containers for shared environments, I'm more concerned
> about security. There is few concerns I have regarding LXC with both
> privileged and unprivileged  containers. 
> 
> -Network stand point
> 
> By default LXC have great network management and integration (with
> privileged containers) but this is without any secure solution about
> network spoofing (MAC, IP, Etc..) 
> I know, maybe it's not LXC's business to manage network like that, but
> looking how good is the project seems to be, I'm really surprised there
> is not any solutions that comes with LXC to integrate those kind of
> (basics) security. 
> 
> One container=>One MAC address=> One or more specifics IP address. 
> 
> Even if the goal of linuxcontainers is to be "vendor neutral" I think
> there something missing here to be more "user friendly" and "out of the
> box" . I think most of LXC user will have more than one containers to
> deploy and it may be the best to provide easy integrated solution
> regarding this specific 
> aspect of networking. 
> 
> I Have been using OpenVswitch (Open Flow) to add such security but from
> what I can tell, this is not documented and self learning on those
> technology take a long time.  You can see the archive here
> : https://www.mail-archive.com/lxc-users@lists.linuxcontainers.org/msg03609.html
> 
> (?) What should the position be when you need to deploy lots of LXC
> containers and give root access to the container ?
> The question doesn't happen with unprivileged containers, looks like
> there is no way to change network info, but this is not the solution if
> you wanna run privileged containers and stay safe. 
> 
> - System security stand point
> 
> Dmesg
> As a simple and quick test, dmesg information of the HOST are in the
> unprivileged container.
> (?) Maybe there is a technical limit about that ? 
> 
> (?) What can be the best way to understand more how build are
> unprivileged container and what can be done to help . Is this only about
> Cgroups? Apparmor ? both?
> Maybe have more information about the interaction between security parts
> will be a nice to have :) 
> 
> 
> - Maturity of the solution with unprivileged containers. 
> I know there is a lot of things going on with this kind of containers. I
> would like to know more about the perspective and the goal . 
> 
> (?) what unprivileged containers are made for ? 
> (?) Is this only to prevent security issues from any process running out
> of an LXC (privileged) container ? 
>      Or is it more to give the opportunity to no-root user to execute
> LXC containers ?
> 
> (?) Let's say it's for security purpose only in case of a process
> running out of a container, how big is the possibility that happen ?
> from one to ten ? 
> 
> Story of my first experience with unprivileged container : 
> 
> I'm running debian jessie to try my first unprivileged container. 
> lxc-create -n debian8 -t downlowd -- -d debian -r jessie -a amd64
> 
> First thing I wanna do, install sshd daemon .  No problem. 
> Second thing, starting sshd after install  : service sshd restart  .
> Result:  [sshd] <defunct>
> Looks like there is something weird...
> service sshd start : Result : Process running  
> But wait, not able to connect . :/
> I had to : sed -ri 's/^session\s+required\s+pam_loginuid.so$/session
> optional pam_loginuid.so/' /etc/pam.d/sshd
> 
> (?)  Now I can connect but "pam_loginuid" cannot be used at all ? 
> 
> Then , what can I see, every SSHD connection failure show a new sshd
> <defunct> process 
> 
> ps auxf|grep sshd|grep defunct|wc -l
> 503
> 
> (?) any idea or know problem ? Is something on my configuration ? 
> 
> It happen with others process like :
> [chef-client] <defunct>
> [bash] <defunct>
> [sshd] <defunct>
> 
> I just wanna understand if those issue are definitively a miss
> configuration on my side or that can be easily explained ? :(
> 
> - init.d with unprivileged 
> (?)  Maybe because I have a lack of knowledge in this area, but why
> there is nothing starting up automatically from a unprivileged container ?
> (?) What can be used as a workaround ?
> 
> 
> Well, beside those points, I can get an unprivileged container running
> httpd, php5, mysql :)
> Pretty quick and easy . Templates are a very good thing to use . (thx)
> 
> Now I'm looking forward to read your experience and share some technical
> or unprivileged containers story !
> 
> Cheers, 
>  
> 
> Cordialement,
> 
> Benoît Georgelin 
> Afin de contribuer au respect de l'environnement, merci de n'imprimer ce
> mail qu'en cas de nécessité
> 
> 
> 
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
> 