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

[Benoit GEORGELIN - Association Web4all]

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é 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20150817/fb99be6f/attachment-0001.html>