Re: [Lxc-users] Mitigating LXC Container Evasion?
On Wed, 2011-08-03 at 22:21 -0700, Casey Schaufler wrote: Smack does not use IPsec on IPv4. Smack uses CIPSO. CIPSO is implemented completely within the kernel. It has no user space component. There is no CIPSO equivalent for IPv6 due to the expectation that all IPv6 implementations will use IPsec and IPsec will address all security issues known to man and then some. Oh, one other point... due to the expectation that all IPv6 implementations will use IPsec and IPsec will address all security issues known to man and then some. Who's assumption? Certainly not that of the IETF. Sounds like some non-sense promulgated by some anti-IPv6 camps and sounds somewhat denigrating and disparaging. It's demonstrably false. We still have MD5 signatures on tcp packets used by BGP on IPv6 (I'm also a contributor to quagga in that very area) even though it was originally expected that AH would replace MD5 signatures for BGP authentication. That expectation went bye-bye many years ago. We still have Kerberos. I don't see anyone going back to telnet instead of ssh over IPv6. We still have SSL over IPv6. The very statement is facetious on its face and can't possibly be taken seriously. If SMACK does not support IPv6 then SMACK is broken. Fix it. IPv6 is a reality. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
On Thu, 2011-08-04 at 09:11 -0700, Casey Schaufler wrote: On 8/4/2011 6:52 AM, Michael H. Warfield wrote: On Wed, 2011-08-03 at 22:21 -0700, Casey Schaufler wrote: Smack does not use IPsec on IPv4. Smack uses CIPSO. CIPSO is implemented completely within the kernel. It has no user space component. There is no CIPSO equivalent for IPv6 due to the expectation that all IPv6 implementations will use IPsec and IPsec will address all security issues known to man and then some. Oh, one other point... due to the expectation that all IPv6 implementations will use IPsec and IPsec will address all security issues known to man and then some. Who's assumption? Certainly not that of the IETF. Sounds like some non-sense promulgated by some anti-IPv6 camps and sounds somewhat denigrating and disparaging. Sorry about that. I was a founding member of TSIG* and we had a very uncomfortable set of interactions with IETF regarding CIPSO and SAMP**. We were very forcefully told to let the IETF provide for us, as we clearly didn't know what we were doing. IPsec was the solution presented, it didn't provide the security attribute transmission we required, and the systems that we needed the solution for had been dismantled long before IPsec was ready for deployment. Yes, there is some bitterness. The Unix trusted systems community never recovered from the lack of a standard that we could use to have the various vendor's systems talk to each other. Gotcha. Yeah, I've been involved with several WGs at the IETF and was one of the original founders of the IDWG WG representing Internet Security Systems at the IETF. It's been described as the highest density of assholes per square meter on the face of the earth. I had an area director pull me into one of the Emergency Preparedness WG meetings one meeting just to sit in an critique the noise that was going on in that one (some of it centered around some disagreements between the ITU and the IETF and what should be provided for emergency responders). The discussion lead by the emergency responders could best be described as: We like toast. Make the Internet make toast. No comprehension. No clue. I understand fully from both sides of those arguments. I'm equally sure they thought the same thing about us. I also understand that CIPSO was a draft for a common implementation of IPSO, RFC 1108, which seems to be largely DoD oriented. I saw the WG finished up business and the last draft expired back in 94 with no RFC (no biggie - XAUTH never got an RFC and I'm up to my behind in the Openswan XAUTH code). There's always been a certain level of tension between the purists in the IETF and others such as the military crowd or ITU or certain commercial interests. I took part in some of the discussions over making IPsec support mandatory in IPv6 back in the bad ole days of ITAR when crypto was a tightly regulated export restricted munition. Yeah, back then, IPsec was presented as a be all and end all and they had dreams of end-to-end encryption for all. And here we are. Reality has had to set in. Sigh. Par for da course. --- * Trusted Systems Interoperability Group ** Security Attribute Modulation Protocol It's demonstrably false. We still have MD5 signatures on tcp packets used by BGP on IPv6 (I'm also a contributor to quagga in that very area) even though it was originally expected that AH would replace MD5 signatures for BGP authentication. That expectation went bye-bye many years ago. We still have Kerberos. I don't see anyone going back to telnet instead of ssh over IPv6. We still have SSL over IPv6. The very statement is facetious on its face and can't possibly be taken seriously. You are of course correct. My comment was sarcastic and inappropriate. NP. I've been rightfully accused of worse myself. If SMACK does not support IPv6 then SMACK is broken. Fix it. That is and has always been the plan. It's really a matter of getting the hands onto it. It's a big project and will require more work than I can plan on getting done in the short term. Well the short course should be just to get the CIPSO tags into IPv6, but that's just IP option 134, right? You really don't need to mess with IPsec one way or the other. I know, I know, there's the whole layer of API and management and what not around it, so it's obviously not so simple as simply adding the AF to those modules. But it should just parallel the v4 code and don't do anything special wrt the IPsec logic. IPv6 is a reality. I never said otherwise. I believe you. Cool. Regards, Mike Likewise, Casey Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc
Re: [Lxc-users] Mitigating LXC Container Evasion?
On Sat, Jul 30, 2011 at 09:10:33PM -0400, Matthew Franz wrote: Had seen some previous discussions before, but are there any ways to mitigate this design vulnerability? http://blog.bofh.it/debian/id_413 Are there any workarounds? Thanks, - mdf -- -- Matthew Franz mdfr...@gmail.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users Hello, If you modify the container's config file like this: lxc.mount.entry=sysfs /usr/local/var/lib/lxc/lxc6/rootfs/sys sysfs ro,defaults 0 0 you can't write to /sys. Patrick -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
On 8/4/2011 6:52 AM, Michael H. Warfield wrote: On Wed, 2011-08-03 at 22:21 -0700, Casey Schaufler wrote: Smack does not use IPsec on IPv4. Smack uses CIPSO. CIPSO is implemented completely within the kernel. It has no user space component. There is no CIPSO equivalent for IPv6 due to the expectation that all IPv6 implementations will use IPsec and IPsec will address all security issues known to man and then some. Oh, one other point... due to the expectation that all IPv6 implementations will use IPsec and IPsec will address all security issues known to man and then some. Who's assumption? Certainly not that of the IETF. Sounds like some non-sense promulgated by some anti-IPv6 camps and sounds somewhat denigrating and disparaging. Sorry about that. I was a founding member of TSIG* and we had a very uncomfortable set of interactions with IETF regarding CIPSO and SAMP**. We were very forcefully told to let the IETF provide for us, as we clearly didn't know what we were doing. IPsec was the solution presented, it didn't provide the security attribute transmission we required, and the systems that we needed the solution for had been dismantled long before IPsec was ready for deployment. Yes, there is some bitterness. The Unix trusted systems community never recovered from the lack of a standard that we could use to have the various vendor's systems talk to each other. --- * Trusted Systems Interoperability Group ** Security Attribute Modulation Protocol It's demonstrably false. We still have MD5 signatures on tcp packets used by BGP on IPv6 (I'm also a contributor to quagga in that very area) even though it was originally expected that AH would replace MD5 signatures for BGP authentication. That expectation went bye-bye many years ago. We still have Kerberos. I don't see anyone going back to telnet instead of ssh over IPv6. We still have SSL over IPv6. The very statement is facetious on its face and can't possibly be taken seriously. You are of course correct. My comment was sarcastic and inappropriate. If SMACK does not support IPv6 then SMACK is broken. Fix it. That is and has always been the plan. It's really a matter of getting the hands onto it. It's a big project and will require more work than I can plan on getting done in the short term. IPv6 is a reality. I never said otherwise. I believe you. Regards, Mike Likewise, Casey -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
On 8/3/2011 9:39 PM, Michael H. Warfield wrote: On Wed, 2011-08-03 at 21:01 -0700, Casey Schaufler wrote: On 8/3/2011 4:24 PM, Serge E. Hallyn wrote: Quoting Andre Nathan (an...@digirati.com.br): Hi Mike On Wed, 2011-08-03 at 17:52 -0400, Michael H. Warfield wrote: That's v4 syntax. Does it not work at all? Did you try this: echo ::/0 @ /smack/netlabel Not having tried this myself at all, I'm just asking. If it doesn't work, that needs to be fixed but it's a SMACK bug. Olivier's IPv4 example works fine, but with IPv6 I get an error: # echo ::/0 @ /smack/netlabel -bash: echo: write error: Invalid argument Looking at linux-2.6/security/smack/smackfs.c, nothing but 'a.b.c.d label' or 'a.b.c.d/mask label' is allowed. Now, smack_lsm.c does suggest that it wants to work with IPV6, but I haven't looked closely enough to tell how it will try to match the labels. Casey, is Smack netlabel supposed to work with IPV6? IPv6 support is a pending work item for Smack. The whole IPSEC thing makes it much more difficult than IPv4. ??? 'struth, as they say down under. Whoa... Hold da phone a minute! I'm a contributor and developer to Openswan (I'm the author of some code for some Cisco ASA compatibility) and other VPN projects. That does not compute to me. How does IPsec make IPv6 more difficult? Are you saying you do not support IPsec on IPv4 but support is required on IPv6 or is there something else in v6 that I'm missing here. IPv6 does complicate things when you get into IKE v2 world where you can directly tunnel a v6 network over v4 endpoints which IKE v1 did not provide for. Is this the problem? The cross protocol encapsulations? Smack does not use IPsec on IPv4. Smack uses CIPSO. CIPSO is implemented completely within the kernel. It has no user space component. There is no CIPSO equivalent for IPv6 due to the expectation that all IPv6 implementations will use IPsec and IPsec will address all security issues known to man and then some. Openswan supports 3 stacks, Netkey (the kernel native), KLIPS (the original FreeS/WAN stack), and Mast. My personal primary focus has been on the Netkey stack which is managed through the ip xfrm commands and functions. To the user space, IPv6 and IPv4 are agnostic. How does v6 in SMACK space become more difficult for v6? It shouldn't be... You're right. If Smack was using IPsec for IPv4 it oughtn't be any more difficult for IPv6. Smack is not using IPsec because it is orders of magnitude more complex than CIPSO. Thus, IPv6 support for Smack is much harder than IPv4 support for Smack was. The difference is not between IPv6 and IPv4, rather it is the difference between IPsec and CIPSO. thanks, -serge Regards, Mike -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Hi Olivier On Tue, 2011-08-02 at 12:13 +0200, Mauras Olivier wrote: Here's a practical example: # smack_label.py -w -r /srv/lxc/lxc1 lxc1 # echo lxc1 /proc/self/current/attr # lxc-start -n lxc1 # echo _ /proc/self/current/attr Does networking inside the containers work for you with this setup? Thanks, Andre -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Hi Andre, You're true it won't work out of the box, sorry i forgot the network part. echo 0.0.0.0/0 @ /smack/netlabel This will resolve the problem. Smack supports Netlabel/CIPSO, but honestly i don't need it so i let full access on this side. You definitely want to check the documentation if you need to fine tune network accesses. Cheers, Olivier On Wed, Aug 3, 2011 at 7:36 PM, Andre Nathan an...@digirati.com.br wrote: Hi Olivier On Tue, 2011-08-02 at 12:13 +0200, Mauras Olivier wrote: Here's a practical example: # smack_label.py -w -r /srv/lxc/lxc1 lxc1 # echo lxc1 /proc/self/current/attr # lxc-start -n lxc1 # echo _ /proc/self/current/attr Does networking inside the containers work for you with this setup? Thanks, Andre -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Hi Olivier On Wed, 2011-08-03 at 19:48 +0200, Mauras Olivier wrote: You're true it won't work out of the box, sorry i forgot the network part. echo 0.0.0.0/0 @ /smack/netlabel Apparently this doesn't support IPv6... do you happen to know of a workaround? Thanks again, Andre -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
On Wed, 2011-08-03 at 17:41 -0300, Andre Nathan wrote: Hi Olivier On Wed, 2011-08-03 at 19:48 +0200, Mauras Olivier wrote: You're true it won't work out of the box, sorry i forgot the network part. echo 0.0.0.0/0 @ /smack/netlabel Apparently this doesn't support IPv6... do you happen to know of a workaround? That's v4 syntax. Does it not work at all? Did you try this: echo ::/0 @ /smack/netlabel Not having tried this myself at all, I'm just asking. If it doesn't work, that needs to be fixed but it's a SMACK bug. Thanks again, Andre Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Hi Mike On Wed, 2011-08-03 at 17:52 -0400, Michael H. Warfield wrote: That's v4 syntax. Does it not work at all? Did you try this: echo ::/0 @ /smack/netlabel Not having tried this myself at all, I'm just asking. If it doesn't work, that needs to be fixed but it's a SMACK bug. Olivier's IPv4 example works fine, but with IPv6 I get an error: # echo ::/0 @ /smack/netlabel -bash: echo: write error: Invalid argument Thanks, Andre -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Quoting Andre Nathan (an...@digirati.com.br): Hi Mike On Wed, 2011-08-03 at 17:52 -0400, Michael H. Warfield wrote: That's v4 syntax. Does it not work at all? Did you try this: echo ::/0 @ /smack/netlabel Not having tried this myself at all, I'm just asking. If it doesn't work, that needs to be fixed but it's a SMACK bug. Olivier's IPv4 example works fine, but with IPv6 I get an error: # echo ::/0 @ /smack/netlabel -bash: echo: write error: Invalid argument Looking at linux-2.6/security/smack/smackfs.c, nothing but 'a.b.c.d label' or 'a.b.c.d/mask label' is allowed. Now, smack_lsm.c does suggest that it wants to work with IPV6, but I haven't looked closely enough to tell how it will try to match the labels. Casey, is Smack netlabel supposed to work with IPV6? thanks, -serge -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
On Wed, 2011-08-03 at 21:01 -0700, Casey Schaufler wrote: On 8/3/2011 4:24 PM, Serge E. Hallyn wrote: Quoting Andre Nathan (an...@digirati.com.br): Hi Mike On Wed, 2011-08-03 at 17:52 -0400, Michael H. Warfield wrote: That's v4 syntax. Does it not work at all? Did you try this: echo ::/0 @ /smack/netlabel Not having tried this myself at all, I'm just asking. If it doesn't work, that needs to be fixed but it's a SMACK bug. Olivier's IPv4 example works fine, but with IPv6 I get an error: # echo ::/0 @ /smack/netlabel -bash: echo: write error: Invalid argument Looking at linux-2.6/security/smack/smackfs.c, nothing but 'a.b.c.d label' or 'a.b.c.d/mask label' is allowed. Now, smack_lsm.c does suggest that it wants to work with IPV6, but I haven't looked closely enough to tell how it will try to match the labels. Casey, is Smack netlabel supposed to work with IPV6? IPv6 support is a pending work item for Smack. The whole IPSEC thing makes it much more difficult than IPv4. ??? Whoa... Hold da phone a minute! I'm a contributor and developer to Openswan (I'm the author of some code for some Cisco ASA compatibility) and other VPN projects. That does not compute to me. How does IPsec make IPv6 more difficult? Are you saying you do not support IPsec on IPv4 but support is required on IPv6 or is there something else in v6 that I'm missing here. IPv6 does complicate things when you get into IKE v2 world where you can directly tunnel a v6 network over v4 endpoints which IKE v1 did not provide for. Is this the problem? The cross protocol encapsulations? Openswan supports 3 stacks, Netkey (the kernel native), KLIPS (the original FreeS/WAN stack), and Mast. My personal primary focus has been on the Netkey stack which is managed through the ip xfrm commands and functions. To the user space, IPv6 and IPv4 are agnostic. How does v6 in SMACK space become more difficult for v6? It shouldn't be... thanks, -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Hello Andre, All labels are set from the host, so it shouldn't matter if a directory is bind mounted or not. For the setup, this is actually pretty straightforward: - You apply the desired label recursively on the container rootdir - See my python script to ease the process here : https://svn.coredumb.net/filedetails.php?repname=Coredumbpath=%2Fscripts%2Ftrunk%2Fpython%2Fsmack_label.py - You change your current label to the desired one - You start the container - You change back your current label Here's a practical example: # smack_label.py -w -r /srv/lxc/lxc1 lxc1 # echo lxc1 /proc/self/current/attr # lxc-start -n lxc1 # echo _ /proc/self/current/attr You now have a container with all its files and processes labelled lxc1. It's now up to you to set the accesses you need. Note: _ or floor is the default label Out from the documentation of Smack: A read or execute access requested on an object labelled _ is permitted. This is the default behaviour and can sure be overridden. If you take my example in my previous mail, i tried to mount sysfs in the container and got it refused cause mounting it read-only is impossible. In the message from the host: type=1400 audit(1312278692.783:33840): lsm=SMACK fn=smack_sb_mount action=denied subject=curse object=_ requested=w pid=19215 comm=mount path=/sys dev=sysfs ino=1 You can see here that object labeled curse tried to access sysfs labeled _ in write mode and got explicitly refused. You could change this behaviour by issuing the following command: echo curse _ rwx /smack/load As you guess this is not what you want to do, cause it would let your container write to the host ;) To summarize, by default only setting a different label - without any complex configuration at all - to your containers will ensure you that a root inside a container could only have minimal impact and/or no impact on the host. The smack setup is only setting up the rules you need to secure your containers and datas inside them. All smack documentation is available in the Kernel sources directory. Hope this helps and that i've made myself clear enough, Olivier On Mon, Aug 1, 2011 at 2:27 PM, Andre Nathan an...@digirati.com.br wrote: Hi Olivier On Sun, 2011-07-31 at 16:42 +0200, Mauras Olivier wrote: Furthermore system has SMACK enabled - Simplified Mandatory Access Control - a label based MAC. Each LXC container has its files and processes labeled differently - Labels which can't write the host system default label, so basically a root in a container can't make anything harmfull on the host system. Same can be achieved _less easily_ with Selinux - Look at IBM papers. Would you mind sharing your SMACK setup? Also, do you know how this applies to bind-mounted directories? Can I label a container's files when they are read-only bind-mounted from the host? Thanks, Andre -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Hi Olivier On Sun, 2011-07-31 at 16:42 +0200, Mauras Olivier wrote: Furthermore system has SMACK enabled - Simplified Mandatory Access Control - a label based MAC. Each LXC container has its files and processes labeled differently - Labels which can't write the host system default label, so basically a root in a container can't make anything harmfull on the host system. Same can be achieved _less easily_ with Selinux - Look at IBM papers. Would you mind sharing your SMACK setup? Also, do you know how this applies to bind-mounted directories? Can I label a container's files when they are read-only bind-mounted from the host? Thanks, Andre -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Hello Matthew, Here's an example in on of my containers: root@nasty:~# ps ax PID TTY STAT TIME COMMAND 1 ?Ss 0:13 init [3] 44 ?Ss 0:02 /usr/sbin/syslogd 141 ?Ss 0:00 /usr/sbin/sshd 144 ?S 0:01 /usr/sbin/crond -l6 149 ?Ss 0:25 /usr/sbin/httpd -k start 2215 ?S 0:14 /usr/sbin/httpd -k start 7820 ?S 0:36 /usr/sbin/httpd -k start 8663 ?S 0:00 /usr/sbin/httpd -k start 10159 ?Ss 0:00 sshd: root@pts/18 10161 pts/18 Ss 0:00 -bash 10175 pts/18 R+ 0:00 ps ax 26928 ?S 0:05 /usr/sbin/httpd -k start 26936 ?S 0:05 /usr/sbin/httpd -k start 26937 ?S 0:05 /usr/sbin/httpd -k start 26938 ?S 0:05 /usr/sbin/httpd -k start 26939 ?S 0:05 /usr/sbin/httpd -k start 28054 ?S 1:41 /usr/sbin/httpd -k start 29670 ?S 0:15 /usr/sbin/httpd -k start root@nasty:~# whoami root root@nasty:~# mount -t sysfs sysfs /sys mount: block device sysfs is write-protected, mounting read-only mount: cannot mount block device sysfs read-only root@nasty:~# touch /test root@nasty:~# rm /test root@nasty:~# cat /sys/kernel/uevent_helper root@nasty:~# echo test /sys/kernel/uevent_helper -bash: /sys/kernel/uevent_helper: Permission denied Here's capabilities dropped on the container: lxc.cap.drop = sys_module mknod lxc.cap.drop = mac_override kill sys_time lxc.cap.drop = setfcap setpcap sys_boot Furthermore system has SMACK enabled - Simplified Mandatory Access Control - a label based MAC. Each LXC container has its files and processes labeled differently - Labels which can't write the host system default label, so basically a root in a container can't make anything harmfull on the host system. Same can be achieved _less easily_ with Selinux - Look at IBM papers. Hope this helps, Olivier On Sun, Jul 31, 2011 at 3:10 AM, Matthew Franz mdfr...@gmail.com wrote: Had seen some previous discussions before, but are there any ways to mitigate this design vulnerability? http://blog.bofh.it/debian/id_413 Are there any workarounds? Thanks, - mdf -- -- Matthew Franz mdfr...@gmail.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Patrick/Oliver, Thanks for the quick response. As a security guy I hate it when folks post weaknesses without providing (or taking the time to investigate) workarounds. And there seems to be a lot of FUD out there on the blogs regarding OpenVZ vs. LXC. :( - mdf On Sun, Jul 31, 2011 at 10:58 AM, root r...@srvweb.net.caen wrote: On Sat, Jul 30, 2011 at 09:10:33PM -0400, Matthew Franz wrote: Had seen some previous discussions before, but are there any ways to mitigate this design vulnerability? http://blog.bofh.it/debian/id_413 Are there any workarounds? Thanks, - mdf -- -- Matthew Franz mdfr...@gmail.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users Hello, If you modify the container's config file like this: lxc.mount.entry=sysfs /usr/local/var/lib/lxc/lxc6/rootfs/sys sysfs ro,defaults 0 0 you can't write to /sys. Patrick -- -- Matthew Franz mdfr...@gmail.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Dnia 2011-07-30, sob o godzinie 21:10 -0400, Matthew Franz pisze: Had seen some previous discussions before, but are there any ways to mitigate this design vulnerability? http://blog.bofh.it/debian/id_413 Are there any workarounds? Thanks, - mdf The blog post explicitly mounts /sys... Why would you want your container to even have the capability to mount anything? If possible, drop CAP_SYS_ADMIN. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
On Sun, 2011-07-31 at 17:59 +0200, Robert Kawecki wrote: Dnia 2011-07-30, sob o godzinie 21:10 -0400, Matthew Franz pisze: Had seen some previous discussions before, but are there any ways to mitigate this design vulnerability? http://blog.bofh.it/debian/id_413 Are there any workarounds? Thanks, - mdf The blog post explicitly mounts /sys... Why would you want your container to even have the capability to mount anything? Let's see... Where shall we start. If you're containerizing a machine or full system there's a laundry list of reasons you would want to. Maybe you want to mount an image, like a CD image or maybe an encrypted file system? Then, there's a variety of fuse file systems you might want access to for a variety of reasons. Maybe you want to run a service, like bind's named in a bind mounted chrooted environment (default for running name servers on Fedora for some time now: /var/named on /var/named/chroot/var/named type none (rw,bind) /var/named/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind) /etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind) /etc/rndc.conf on /var/named/chroot/etc/rndc.conf type none (rw,bind) /etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind) /usr/lib/bind on /var/named/chroot/usr/lib/bind type none (rw,bind) /etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind) /etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind) That gets done by service named start. If possible, drop CAP_SYS_ADMIN. That's been proposed as a workaround for some of the remount problems we have to where a partition is suppose to be mounted ro but the container can remount it rw. I've actually tried that trick. Yeah, that was an epic failure. Generally not possible in a generalized system container. Way too many things are impacted by CAP_SYS_ADMIN. Disabling that, you can't even set your own hostname in the container. You can't set crypto keys either. That's a sledge hammer approach that won't work in many if not most system containers. A simply application container? It might work in, depending on the application. Check out man capabilities and scroll down to CAP_SYS_ADMIN and look at that laundry list under it (and I'm not totally sure that list is comprehensive in the man page either) and honestly say there are not reasons for a container wanting to do at least one or two of them (even given that every container I have sets its own hostname). Gotta be a better answer than that. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
That's where MAC system comes handy. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Michael H. Warfield m...@wittsend.com wrote: On Sun, 2011-07-31 at 17:59 +0200, Robert Kawecki wrote: Dnia 2011-07-30, sob o godzinie 21:10 -0400, Matthew Franz pisze: Had seen some previous discussions before, but are there any ways to mitigate this design vulnerability? http://blog.bofh.it/debian/id_413 Are there any workarounds? Thanks, - mdf The blog post explicitly mounts /sys... Why would you want your container to even have the capability to mount anything? Let's see... Where shall we start. If you're containerizing a machine or full system there's a laundry list of reasons you would want to. Maybe you want to mount an image, like a CD image or maybe an encrypted file system? Then, there's a variety of fuse file systems you might want access to for a variety of reasons. Maybe you want to run a service, like bind's named in a bind mounted chrooted environment (default for running name servers on Fedora for some time now: /var/named on /var/named/chroot/var/named type none (rw,bind) /var/named/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind) /etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind) /etc/rndc.conf on /var/named/chroot/etc/rndc.conf type none (rw,bind) /etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind) /usr/lib/bind on /var/named/chroot/usr/lib/bind type none (rw,bind) /etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind) /etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind) That gets done by service named start. If possible, drop CAP_SYS_ADMIN. That's been proposed as a workaround for some of the remount problems we have to where a partition is suppose to be mounted ro but the container can remount it rw. I've actually tried that trick. Yeah, that was an epic failure. Generally not possible in a generalized system container. Way too many things are impacted by CAP_SYS_ADMIN. Disabling that, you can't even set your own hostname in the container. You can't set crypto keys either. That's a sledge hammer approach that won't work in many if not most system containers. A simply application container? It might work in, depending on the application. Check out man capabilities and scroll down to CAP_SYS_ADMIN and look at that laundry list under it (and I'm not totally sure that list is comprehensive in the man page either) and honestly say there are not reasons for a container wanting to do at least one or two of them (even given that every container I have sets its own hostname). Gotta be a better answer than that. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! _ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey_ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
On Sun, 2011-07-31 at 23:02 +0200, Olivier Mauras wrote: That's where MAC system comes handy. Was just reading up on that from your earlier post. Very nice. I see I have some reading a research to do. I posted a URL to an IBM paper in a reply to your earlier post. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Michael H. Warfield m...@wittsend.com wrote: On Sun, 2011-07-31 at 17:59 +0200, Robert Kawecki wrote: Dnia 2011-07-30, sob o godzinie 21:10 -0400, Matthew Franz pisze: Had seen some previous discussions before, but are there any ways to mitigate this design vulnerability? http://blog.bofh.it/debian/id_413 Are there any workarounds? Thanks, - mdf The blog post explicitly mounts /sys... Why would you want your container to even have the capability to mount anything? Let's see... Where shall we start. If you're containerizing a machine or full system there's a laundry list of reasons you would want to. Maybe you want to mount an image, like a CD image or maybe an encrypted file system? Then, there's a variety of fuse file systems you might want access to for a variety of reasons. Maybe you want to run a service, like bind's named in a bind mounted chrooted environment (default for running name servers on Fedora for some time now: /var/named on /var/named/chroot/var/named type none (rw,bind) /var/named/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind) /etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind) /etc/rndc.conf on /var/named/chroot/etc/rndc.conf type none (rw,bind) /etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind) /usr/lib/bind on /var/named/chroot/usr/lib/bind type none (rw,bind) /etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind) /etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind) That gets done by service named start. If possible, drop CAP_SYS_ADMIN. That's been proposed as a workaround for some of the remount problems we have to where a partition is suppose to be mounted ro but the container can remount it rw. I've actually tried that trick. Yeah, that was an epic failure. Generally not possible in a generalized system container. Way too many things are impacted by CAP_SYS_ADMIN. Disabling that, you can't even set your own hostname in the container. You can't set crypto keys either. That's a sledge hammer approach that won't work in many if not most system containers. A simply application container? It might work in, depending on the application. Check out man capabilities and scroll down to CAP_SYS_ADMIN and look at that laundry list under it (and I'm not totally sure that list is comprehensive in the man page either) and honestly say there are not reasons for a container wanting to do at least one or two of them (even given that every container I have sets its own hostname). Gotta be a better answer than that. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! _ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey_ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ Lxc-users mailing list Lxc-users@lists.sourceforge.net
Re: [Lxc-users] Mitigating LXC Container Evasion?
Yes I started using smack after digging trough this article :) As for capabilities I usually start from the most restrictive, removing one by one until I want the container to work as expected. Regards, Olivier -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Michael H. Warfield m...@wittsend.com wrote: On Sun, 2011-07-31 at 23:02 +0200, Olivier Mauras wrote: That's where MAC system comes handy. Was just reading up on that from your earlier post. Very nice. I see I have some reading a research to do. I posted a URL to an IBM paper in a reply to your earlier post. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Michael H. Warfield m...@wittsend.com wrote: On Sun, 2011-07-31 at 17:59 +0200, Robert Kawecki wrote: Dnia 2011-07-30, sob o godzinie 21:10 -0400, Matthew Franz pisze: Had seen some previous discussions before, but are there any ways to mitigate this design vulnerability? http://blog.bofh.it/debian/id_413 Are there any workarounds? Thanks, - mdf The blog post explicitly mounts /sys... Why would you want your container to even have the capability to mount anything? Let's see... Where shall we start. If you're containerizing a machine or full system there's a laundry list of reasons you would want to. Maybe you want to mount an image, like a CD image or maybe an encrypted file system? Then, there's a variety of fuse file systems you might want access to for a variety of reasons. Maybe you want to run a service, like bind's named in a bind mounted chrooted environment (default for running name servers on Fedora for some time now: /var/named on /var/named/chroot/var/named type none (rw,bind) /var/named/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind) /etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind) /etc/rndc.conf on /var/named/chroot/etc/rndc.conf type none (rw,bind) /etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind) /usr/lib/bind on /var/named/chroot/usr/lib/bind type none (rw,bind) /etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind) /etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind) That gets done by service named start. If possible, drop CAP_SYS_ADMIN. That's been proposed as a workaround for some of the remount problems we have to where a partition is suppose to be mounted ro but the container can remount it rw. I've actually tried that trick. Yeah, that was an epic failure. Generally not possible in a generalized system container. Way too many things are impacted by CAP_SYS_ADMIN. Disabling that, you can't even set your own hostname in the container. You can't set crypto keys either. That's a sledge hammer approach that won't work in many if not most system containers. A simply application container? It might work in, depending on the application. Check out man capabilities and scroll down to CAP_SYS_ADMIN and look at that laundry list under it (and I'm not totally sure that list is comprehensive in the man page either) and honestly say there are not reasons for a container wanting to do at least one or two of them (even given that every container I have sets its own hostname). Gotta be a better answer than that. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! _ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey_ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users _ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on
