Re: [openstack-dev] [glance][ironic][cinder][nova] 'tar' as an image disk_format
Update: The discussion went in two directions: (1) Whether supporting OS tarballs in Ironic is a good idea ... continuing discussion on the Ironic spec, https://review.openstack.org/#/c/248968/ (2) How an OS tarball should be identified in Glance ... continuing discussion on the Glance spec-lite, https://bugs.launchpad.net/glance/+bug/1535900 If you have an opinion, please leave a comment in the appropriate place. thanks, brian On 1/23/16, 9:54 AM, "Brian Rosmaita" wrote: >Please provide feedback about a proposal to add 'tar' as a new Glance >disk_format.[0] > >The Ironic team is adding support for "OS tarball images" in Mitaka. >This is a compressed tar archive of a / (root filesystem). These tarballs >are created by first installing the OS packages in a chroot and then >compressing the chroot as tar.*. The proposal > is to store such images as disk_format == tar and container_format == >bare. > >Intuitively, 'tar' seems more like a container_format. The Glance >developer documentation, however, says that "The container format refers >to whether the virtual machine image is in a file format that also >contains metadata about the actual virtual machine."[1] > Under this proposal, there is no such metadata included. > >The Glance docs say this about disk_format: "The disk format of a virtual >machine image is the format of the underlying disk image. Virtual >appliance vendors have different formats for laying out the information >contained in a virtual machine disk image."[1] > Under this definition, 'tar' as used in this proposal [0] does in fact >seem to be a disk_format. > >There is not currently a 'tar' container format defined for Glance. The >closest we have now is 'ova' (an OVA tar archive file) and 'docker' (a >Docker tar archive of the container filesystem). And, in fact, 'tar' as >a container format wouldn't be very > helpful, as it doesn't indicate where in the tarball the metadata should >be found. > >The goal here is to come up with an identifier for an "OS tarball image" >that's acceptable across projects and isn't confusing for people who are >creating images. > >Thanks in advance for your feedback, >brian > >[0] https://bugs.launchpad.net/glance/+bug/1535900 >[1] https://github.com/openstack/glance/blob/master/doc/source/formats.rst > __ 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
Hi Flavio, On Wed, Jan 27, 2016 at 4:50 AM, Flavio Percoco wrote: > [snip] > However, as a community, I think we should send a clear message and protect > our users and, in this case, the best way > is to avoid adding this format as supported. > To address some of the concerns i have added a security impact statement on the spec 1. Ironic doesn't unpack the OS tarball, it will be unpacked on the target node in a ramdisk using tar utility. (tar -avxf) 2. The moment you allow an un-trusted OS image to be deployed, the expected security is None. An advisory doesn't need to manipulate the extraction of the tarball to gain access in that case. 3. In docker the vulnerability is high because a vulnerable container can infect the host system. 4. I understand the concerns with the conversion API's , and they are valid. Please feel free to not support tar as a conversion target. -- Arun S A G http://zer0c00l.in/ __ 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
On Wed, Jan 27, 2016 at 08:32:58AM -0430, Flavio Percoco wrote: > On 27/01/16 08:20 -0430, Flavio Percoco wrote: > >On 26/01/16 09:11 +, Daniel P. Berrange wrote: > >>On Sun, Jan 24, 2016 at 12:00:16AM +0200, Duncan Thomas wrote: > >>>I guess my wisdom would be 'why'? What does this enable you to do that you > >>>couldn't do with similar ease with the formats we have and are people > >>>trying to do that frequently. > >>> > >>>We've seen in cinder that image formats have a definite security surface to > >>>them, and with glance adding arbitrary conversion pipelines, that surface > >>>is going to increase with every format we add. This should mean we tend > >>>towards being increasingly conservative I think. > >> > >>Safely extracting tar file contents to create a disk image to run the VM > >>from is particularly non-trivial. There have been many security flaws in > >>the past with apps doing tar file unpacking in this kind of scenario. For > >>example, Docker has had not one, but *three* vulnerabilities in this area > >>CVE-2014-6407, CVE-2014-9356, and CVE-2014-9357. So unless there is a > >>pretty compelling reason, I'd suggest we stay away from supporting tar > >>as an image format, and require traditional image formats where we we can > >>treat the file payload as an opaque blob and thus avoid all these file > >>processing risks. > > > >++ > > > >From a Glance perspective, there wouldn't be much to do and most of the > >security > >issues would live in the Ironic side. However, as a community, I think we > >should > >send a clear message and protect our users and, in this case, the best way > >is to > >avoid adding this format as supported. > > > >In future works (image conversions and whatnot) this could impact Glance as > >well. > > It was brought to my attention (thanks Erno) that we support OVA already. This > means we're basically exposed to the above already as the OVA container is a > tarball anyway. > > Glance protects itself from this by either not doing anything to the image or > isolating operations on the image to specific workers (of course, this goes in > addition to other security measures). > > The difference, though, is that OVA files are a known container format for > images, whereas tar.gz isn't. NB nova doesn't do anything with OVA files either. IIRC, the only virt driver that supports them is VMWare, and Nova just passes the file through as-is to VMWare for processing. For libvirt / KVM we don't support OVS files at all, partly because we don't want to be in the business of unpacking them and turning them into disk images ourselves. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
On 27/01/16 08:20 -0430, Flavio Percoco wrote: On 26/01/16 09:11 +, Daniel P. Berrange wrote: On Sun, Jan 24, 2016 at 12:00:16AM +0200, Duncan Thomas wrote: I guess my wisdom would be 'why'? What does this enable you to do that you couldn't do with similar ease with the formats we have and are people trying to do that frequently. We've seen in cinder that image formats have a definite security surface to them, and with glance adding arbitrary conversion pipelines, that surface is going to increase with every format we add. This should mean we tend towards being increasingly conservative I think. Safely extracting tar file contents to create a disk image to run the VM from is particularly non-trivial. There have been many security flaws in the past with apps doing tar file unpacking in this kind of scenario. For example, Docker has had not one, but *three* vulnerabilities in this area CVE-2014-6407, CVE-2014-9356, and CVE-2014-9357. So unless there is a pretty compelling reason, I'd suggest we stay away from supporting tar as an image format, and require traditional image formats where we we can treat the file payload as an opaque blob and thus avoid all these file processing risks. ++ From a Glance perspective, there wouldn't be much to do and most of the security issues would live in the Ironic side. However, as a community, I think we should send a clear message and protect our users and, in this case, the best way is to avoid adding this format as supported. In future works (image conversions and whatnot) this could impact Glance as well. It was brought to my attention (thanks Erno) that we support OVA already. This means we're basically exposed to the above already as the OVA container is a tarball anyway. Glance protects itself from this by either not doing anything to the image or isolating operations on the image to specific workers (of course, this goes in addition to other security measures). The difference, though, is that OVA files are a known container format for images, whereas tar.gz isn't. Flavio Cheers, Flavio Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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 -- @flaper87 Flavio Percoco __ 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 -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
On 26/01/16 09:11 +, Daniel P. Berrange wrote: On Sun, Jan 24, 2016 at 12:00:16AM +0200, Duncan Thomas wrote: I guess my wisdom would be 'why'? What does this enable you to do that you couldn't do with similar ease with the formats we have and are people trying to do that frequently. We've seen in cinder that image formats have a definite security surface to them, and with glance adding arbitrary conversion pipelines, that surface is going to increase with every format we add. This should mean we tend towards being increasingly conservative I think. Safely extracting tar file contents to create a disk image to run the VM from is particularly non-trivial. There have been many security flaws in the past with apps doing tar file unpacking in this kind of scenario. For example, Docker has had not one, but *three* vulnerabilities in this area CVE-2014-6407, CVE-2014-9356, and CVE-2014-9357. So unless there is a pretty compelling reason, I'd suggest we stay away from supporting tar as an image format, and require traditional image formats where we we can treat the file payload as an opaque blob and thus avoid all these file processing risks. ++ From a Glance perspective, there wouldn't be much to do and most of the security issues would live in the Ironic side. However, as a community, I think we should send a clear message and protect our users and, in this case, the best way is to avoid adding this format as supported. In future works (image conversions and whatnot) this could impact Glance as well. Cheers, Flavio Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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 -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
On Sun, Jan 24, 2016 at 12:00:16AM +0200, Duncan Thomas wrote: > I guess my wisdom would be 'why'? What does this enable you to do that you > couldn't do with similar ease with the formats we have and are people > trying to do that frequently. > > We've seen in cinder that image formats have a definite security surface to > them, and with glance adding arbitrary conversion pipelines, that surface > is going to increase with every format we add. This should mean we tend > towards being increasingly conservative I think. Safely extracting tar file contents to create a disk image to run the VM from is particularly non-trivial. There have been many security flaws in the past with apps doing tar file unpacking in this kind of scenario. For example, Docker has had not one, but *three* vulnerabilities in this area CVE-2014-6407, CVE-2014-9356, and CVE-2014-9357. So unless there is a pretty compelling reason, I'd suggest we stay away from supporting tar as an image format, and require traditional image formats where we we can treat the file payload as an opaque blob and thus avoid all these file processing risks. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
Hi Duncan, On Sat, Jan 23, 2016 at 2:00 PM, Duncan Thomas wrote: > I guess my wisdom would be 'why'? What does this enable you to do that you > couldn't do with similar ease with the formats we have and are people trying > to do that frequently. > As far as i know the ironic only supports creating gpt partitions in UEFI mode. GPT partitions are needed if the disk size is more than 2 TB. The whole disk image generated by DIB only supports MSDOS disk labels. However with tar payload we are supporting both MSDOS and GPT disk labels. GPT is a must in a data center environment that bios boot's the server and have >2TB HDD's. This is one use case i think of. Please correct me if i am wrong here. Tar based OS images are simple, They are created by installing packages in a chroot and compressing them as tar. This is simpler than building disk images where file systems and loop devices have to be created. Tar based images are faster to transfer over the network than whole disk images. Tar based OS images are getting popular, especially redhat installers like anaconda are already supporting them. > We've seen in cinder that image formats have a definite security surface to > them, and with glance adding arbitrary conversion pipelines, that surface is > going to increase with every format we add. This should mean we tend towards > being increasingly conservative I think. > I understand that this creates more headaches in cinder. > We've heard a possible feature, but zero use case that I can see. Why is > this better than converting your days to a supported format? The feature is called 'tar-payload' converting to any other format doesn't make sense. Do you have a suggestion as to what format we should consider converting to instead of adding a disk_format named tar? -- Arun S A G http://zer0c00l.in/ __ 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
On 23/01/16 09:08 -0800, Clint Byrum wrote: Excerpts from Brian Rosmaita's message of 2016-01-23 06:54:26 -0800: Please provide feedback about a proposal to add 'tar' as a new Glance disk_format.[0] The Ironic team is adding support for "OS tarball images" in Mitaka. This is a compressed tar archive of a / (root filesystem). These tarballs are created by first installing the OS packages in a chroot and then compressing the chroot as tar.*. The proposal is to store such images as disk_format == tar and container_format == bare. Intuitively, 'tar' seems more like a container_format. The Glance developer documentation, however, says that "The container format refers to whether the virtual machine image is in a file format that also contains metadata about the actual virtual machine."[1] Under this proposal, there is no such metadata included. The Glance docs say this about disk_format: "The disk format of a virtual machine image is the format of the underlying disk image. Virtual appliance vendors have different formats for laying out the information contained in a virtual machine disk image."[1] Under this definition, 'tar' as used in this proposal [0] does in fact seem to be a disk_format. There is not currently a 'tar' container format defined for Glance. The closest we have now is 'ova' (an OVA tar archive file) and 'docker' (a Docker tar archive of the container filesystem). And, in fact, 'tar' as a container format wouldn't be very helpful, as it doesn't indicate where in the tarball the metadata should be found. The goal here is to come up with an identifier for an "OS tarball image" that's acceptable across projects and isn't confusing for people who are creating images. Seems fine to just have tar be both the container and image format, even if it means the metadata portion just turns out to be null. Right? The key is to be able to feed it to hypervisors that can deal with it, and Ironic is presumably able to deal with it since they're asking for it. Yeah, this could work as well. It'd be weird to have it been both but I guess that's fine from a metadata perspective. An image's container and disk format shouldn't be the same for the same image, though. Unless I'm missing something. Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
I guess my wisdom would be 'why'? What does this enable you to do that you couldn't do with similar ease with the formats we have and are people trying to do that frequently. We've seen in cinder that image formats have a definite security surface to them, and with glance adding arbitrary conversion pipelines, that surface is going to increase with every format we add. This should mean we tend towards being increasingly conservative I think. We've heard a possible feature, but zero use case that I can see. Why is this better than converting your days to a supported format? On 23 Jan 2016 16:57, "Brian Rosmaita" wrote: > Please provide feedback about a proposal to add 'tar' as a new Glance > disk_format.[0] > > The Ironic team is adding support for "OS tarball images" in Mitaka. This > is a compressed tar archive of a / (root filesystem). These tarballs are > created by first installing the OS packages in a chroot and then > compressing the chroot as tar.*. The proposal is to store such images as > disk_format == tar and container_format == bare. > > Intuitively, 'tar' seems more like a container_format. The Glance > developer documentation, however, says that "The container format refers to > whether the virtual machine image is in a file format that also contains > metadata about the actual virtual machine."[1] Under this proposal, there > is no such metadata included. > > The Glance docs say this about disk_format: "The disk format of a virtual > machine image is the format of the underlying disk image. Virtual appliance > vendors have different formats for laying out the information contained in > a virtual machine disk image."[1] Under this definition, 'tar' as used in > this proposal [0] does in fact seem to be a disk_format. > > There is not currently a 'tar' container format defined for Glance. The > closest we have now is 'ova' (an OVA tar archive file) and 'docker' (a > Docker tar archive of the container filesystem). And, in fact, 'tar' as a > container format wouldn't be very helpful, as it doesn't indicate where in > the tarball the metadata should be found. > > The goal here is to come up with an identifier for an "OS tarball image" > that's acceptable across projects and isn't confusing for people who are > creating images. > > Thanks in advance for your feedback, > brian > > [0] https://bugs.launchpad.net/glance/+bug/1535900 > [1] https://github.com/openstack/glance/blob/master/doc/source/formats.rst > > > __ > 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 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
Excerpts from Brian Rosmaita's message of 2016-01-23 06:54:26 -0800: > Please provide feedback about a proposal to add 'tar' as a new Glance > disk_format.[0] > > The Ironic team is adding support for "OS tarball images" in Mitaka. This is > a compressed tar archive of a / (root filesystem). These tarballs are created > by first installing the OS packages in a chroot and then compressing the > chroot as tar.*. The proposal is to store such images as disk_format == tar > and container_format == bare. > > Intuitively, 'tar' seems more like a container_format. The Glance developer > documentation, however, says that "The container format refers to whether the > virtual machine image is in a file format that also contains metadata about > the actual virtual machine."[1] Under this proposal, there is no such > metadata included. > > The Glance docs say this about disk_format: "The disk format of a virtual > machine image is the format of the underlying disk image. Virtual appliance > vendors have different formats for laying out the information contained in a > virtual machine disk image."[1] Under this definition, 'tar' as used in this > proposal [0] does in fact seem to be a disk_format. > > There is not currently a 'tar' container format defined for Glance. The > closest we have now is 'ova' (an OVA tar archive file) and 'docker' (a Docker > tar archive of the container filesystem). And, in fact, 'tar' as a container > format wouldn't be very helpful, as it doesn't indicate where in the tarball > the metadata should be found. > > The goal here is to come up with an identifier for an "OS tarball image" > that's acceptable across projects and isn't confusing for people who are > creating images. > Seems fine to just have tar be both the container and image format, even if it means the metadata portion just turns out to be null. Right? The key is to be able to feed it to hypervisors that can deal with it, and Ironic is presumably able to deal with it since they're asking for it. __ 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] [glance][ironic][cinder][nova] 'tar' as an image disk_format
Please provide feedback about a proposal to add 'tar' as a new Glance disk_format.[0] The Ironic team is adding support for "OS tarball images" in Mitaka. This is a compressed tar archive of a / (root filesystem). These tarballs are created by first installing the OS packages in a chroot and then compressing the chroot as tar.*. The proposal is to store such images as disk_format == tar and container_format == bare. Intuitively, 'tar' seems more like a container_format. The Glance developer documentation, however, says that "The container format refers to whether the virtual machine image is in a file format that also contains metadata about the actual virtual machine."[1] Under this proposal, there is no such metadata included. The Glance docs say this about disk_format: "The disk format of a virtual machine image is the format of the underlying disk image. Virtual appliance vendors have different formats for laying out the information contained in a virtual machine disk image."[1] Under this definition, 'tar' as used in this proposal [0] does in fact seem to be a disk_format. There is not currently a 'tar' container format defined for Glance. The closest we have now is 'ova' (an OVA tar archive file) and 'docker' (a Docker tar archive of the container filesystem). And, in fact, 'tar' as a container format wouldn't be very helpful, as it doesn't indicate where in the tarball the metadata should be found. The goal here is to come up with an identifier for an "OS tarball image" that's acceptable across projects and isn't confusing for people who are creating images. Thanks in advance for your feedback, brian [0] https://bugs.launchpad.net/glance/+bug/1535900 [1] https://github.com/openstack/glance/blob/master/doc/source/formats.rst __ 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
