Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap discussions at OSSG mid-cycle
Brant, I started work to use rootwrap as daemon in Nova fyi: https://review.openstack.org/#/c/180695/ Don't know if this will help -- dims On Thu, May 14, 2015 at 11:55 AM, Brant Knudson b...@acm.org wrote: On Thu, May 14, 2015 at 2:48 AM, Angus Lees g...@inodes.org wrote: On Wed, 13 May 2015 at 02:16 Thierry Carrez thie...@openstack.org wrote: Lucas Fisher wrote: We spent some time at the OSSG mid-cycle meet-up this week discussing root wrap, looking at the existing code, and considering some of the mailing list discussions. Summary of our discussions: https://github.com/hyakuhei/OSSG-Security-Practices/blob/master/ossg_rootwrap.md The one line summary is we like the idea of a privileged daemon with higher level interfaces to the commands being run. It has a number of advantages such as easier to audit, enables better input sanitization, cleaner interfaces, and easier to take advantage of Linux capabilities, SELinux, AppArmour, etc. The write-up has some more details. For those interested in that topic and willing to work on the next stage, we'll have a work session on the future of rootwrap in the Oslo track at the Design Summit in Vancouver: http://sched.co/3B2B Fwiw, I've continued work on my privsep proposal(*) and how it interacts with existing rootwrap. I look forward to discussing it and alternatives at the session. (*) https://review.openstack.org/#/c/155631 - Gus As part of the OSSG work, I started prototyping changes in Nova where the goal is to 1) Get all the code that's calling rootwrap into one place so that it's easy to find, and get tests for this code. 2) Next (or even in step 1 if it's easy enough), tighten the interfaces, so that rather than providing a function to do chmod %s %s it would only allow whatever chmod nova actually has to do, maybe passing in a server ID rather than a bare file name. With this, we should be able to tighten up the rootwrap filters in the same way, or switch to privsep or whatever we decide to do in the future. So maybe it looks like rearranging deckchairs on the titanic, but in this case the deckchairs are blocking the emergency exits. I didn't get too far in it to even see how viable the approach is since I was working on other things. I'll put this session on my calendar. - Brant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap discussions at OSSG mid-cycle
On Thu, May 14, 2015 at 2:48 AM, Angus Lees g...@inodes.org wrote: On Wed, 13 May 2015 at 02:16 Thierry Carrez thie...@openstack.org wrote: Lucas Fisher wrote: We spent some time at the OSSG mid-cycle meet-up this week discussing root wrap, looking at the existing code, and considering some of the mailing list discussions. Summary of our discussions: https://github.com/hyakuhei/OSSG-Security-Practices/blob/master/ossg_rootwrap.md The one line summary is we like the idea of a privileged daemon with higher level interfaces to the commands being run. It has a number of advantages such as easier to audit, enables better input sanitization, cleaner interfaces, and easier to take advantage of Linux capabilities, SELinux, AppArmour, etc. The write-up has some more details. For those interested in that topic and willing to work on the next stage, we'll have a work session on the future of rootwrap in the Oslo track at the Design Summit in Vancouver: http://sched.co/3B2B Fwiw, I've continued work on my privsep proposal(*) and how it interacts with existing rootwrap. I look forward to discussing it and alternatives at the session. (*) https://review.openstack.org/#/c/155631 - Gus As part of the OSSG work, I started prototyping changes in Nova where the goal is to 1) Get all the code that's calling rootwrap into one place so that it's easy to find, and get tests for this code. 2) Next (or even in step 1 if it's easy enough), tighten the interfaces, so that rather than providing a function to do chmod %s %s it would only allow whatever chmod nova actually has to do, maybe passing in a server ID rather than a bare file name. With this, we should be able to tighten up the rootwrap filters in the same way, or switch to privsep or whatever we decide to do in the future. So maybe it looks like rearranging deckchairs on the titanic, but in this case the deckchairs are blocking the emergency exits. I didn't get too far in it to even see how viable the approach is since I was working on other things. I'll put this session on my calendar. - Brant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap discussions at OSSG mid-cycle
On Wed, 13 May 2015 at 02:16 Thierry Carrez thie...@openstack.org wrote: Lucas Fisher wrote: We spent some time at the OSSG mid-cycle meet-up this week discussing root wrap, looking at the existing code, and considering some of the mailing list discussions. Summary of our discussions: https://github.com/hyakuhei/OSSG-Security-Practices/blob/master/ossg_rootwrap.md The one line summary is we like the idea of a privileged daemon with higher level interfaces to the commands being run. It has a number of advantages such as easier to audit, enables better input sanitization, cleaner interfaces, and easier to take advantage of Linux capabilities, SELinux, AppArmour, etc. The write-up has some more details. For those interested in that topic and willing to work on the next stage, we'll have a work session on the future of rootwrap in the Oslo track at the Design Summit in Vancouver: http://sched.co/3B2B Fwiw, I've continued work on my privsep proposal(*) and how it interacts with existing rootwrap. I look forward to discussing it and alternatives at the session. (*) https://review.openstack.org/#/c/155631 - Gus __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap discussions at OSSG mid-cycle
Lucas Fisher wrote: We spent some time at the OSSG mid-cycle meet-up this week discussing root wrap, looking at the existing code, and considering some of the mailing list discussions. Summary of our discussions: https://github.com/hyakuhei/OSSG-Security-Practices/blob/master/ossg_rootwrap.md The one line summary is we like the idea of a privileged daemon with higher level interfaces to the commands being run. It has a number of advantages such as easier to audit, enables better input sanitization, cleaner interfaces, and easier to take advantage of Linux capabilities, SELinux, AppArmour, etc. The write-up has some more details. For those interested in that topic and willing to work on the next stage, we'll have a work session on the future of rootwrap in the Oslo track at the Design Summit in Vancouver: http://sched.co/3B2B -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][cinder][neutron][security] Rootwrap discussions at OSSG mid-cycle
All, We spent some time at the OSSG mid-cycle meet-up this week discussing root wrap, looking at the existing code, and considering some of the mailing list discussions. Summary of our discussions: https://github.com/hyakuhei/OSSG-Security-Practices/blob/master/ossg_rootwrap.md The one line summary is we like the idea of a privileged daemon with higher level interfaces to the commands being run. It has a number of advantages such as easier to audit, enables better input sanitization, cleaner interfaces, and easier to take advantage of Linux capabilities, SELinux, AppArmour, etc. The write-up has some more details. -- Lucas Fisher Senior Security Software Engineer | Nebula Inc. lucas.fis...@nebula.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
