-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2013 09:16 PM, Josh Bressers wrote: > > > ----- Original Message ----- >> Hi security team. I'm working on >> >> https://fedoraproject.org/wiki/Changes/VisibleCloud >> >> which proposes promoting the Fedora Cloud image on basically >> equal footing with the desktop download. Daniel Berrange gave the >> useful feedback that while installation-based distribution allows >> one to install updates at build time, image-based distribution >> means that the image must be booted to apply updates, giving a >> window of insecurity. (Unless careful measures are taken.) >> >> When there was a security issue with the previous Fedora image, >> we did do a fire-drill with an adhoc respin and pushed new >> images. Dan suggests that we develop (in coordination with the qa >> and release engineering teams) a security policy for updates to >> the cloud image. >> >> Is this of interest? >> > > I think this is of great interest to us. It's a whole new way of > thinking about the distribution. New concepts like this always > bring new challenges. Speaking as the SRT guy responsible for the RHT end of this fire drill this is something we want to avoid in future, and some things are already in progress, once I make some progress I was planning to talk to the Fedora (and possibly others). > So needing to respin images is almost certainly going to happen. I > suspect there isn't going to be an easy way to define what that is > though. Some people might care about local root issues, remote root > is obviously bad no matter what. What about system level denial of > service? The attack surface potential here is going to be REALLY > high. Our challenge will be to think of this not as a normal > distribution, but as a cloud image (which I'm currently not doing > in my head). One problem with AWS for example is even if you respin the image it has a new AMI (Amazon Machine Instance) ID, so any systems launching Fedora servers automatically will include that old AMI ID until it is manually updated. Only people going through the Marketplace or searching for "Fedora" will get the latest one. > I'm unsure what I think about the concern with needing to boot an > image to apply updates. This is true of a fresh install, no? This > update problem will be dictated by what's running on an image at > boot time. In general we are safe here, the default images just have OpenSSH exposed to the world, if that has a remote exploit we have much larger problems than our cloud images (like .. everything on the planet being hacked). > Anyhow, I think this is a good conversation opener. If anyone has > any ideas about what we should be worried about, thinking about, or > if you have a clever idea, let us know. I had thought about a stub RPM like "cloud-update" that could contain cloud specific updates/etc, some problems crop up like do we do one per service provider (since we can't reliably detect which provider we're on without doing some potentially dangerous things), who maintains it, how do we handle situations where we push out an emergency update through the cloud-update thing and then push an actual updated cloud image, we need to ensure the image and the cloud-update don't conflict to name a few of the simpler problems. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQIcBAEBAgAGBQJR5NBNAAoJEBYNRVNeJnmTqI8QAMyXhklTEwdlFG4QNZkk845P 9NNbQV+VZCujj+cPAOKg0xAIG18OM4nb5kvwl4Lq2kh5Q0eU353mBoGxaL/W4YwL LhI6Y0MSqX1N28AkinrSTpxHziv45kWSiWHra3O8bixAWORsBkYOpCnzma0V1IMC G1JhWWT1ic/ZO6XbDHhemD2IOkmJBae5WQ4wUTsR4Di5ZjxVdb9HYmg5Rkuq8CY0 oChC4rf3Wxa08Y5e+zCUzjMTu2lXRVNuQZAaFx6ZAV/rEBIirIvX3GyZSWKsBIVU 4pFSa/nxiDp+4kbnRMEuc/pnJgrocXvve+qNFq0WAdMZb4lUYNrgp+1UHrPGTbNC VdQFOC49TWbKO1DFoGAWoW06raxiuW8Uq049EmYBHp7L6lCwcu0k3mRSlItDXktc NjVdSgExRkyStxl0fhD7pmlCFDOGdi57IjAihhl7NwnfvIP3GX7O/yrNsUYL2hIO rfZXekRwl9irw6O8JtuR5fZ3DTL2pHIhy3kEiDqw6bIM4pSiPzoZAiojm1qf2pfG m/jLfF1ZxUME9RRyvqvIOfoaaxN0atkrDYpCTygaUp2b2u5GubTxYBW3d02qT32z 8JT0gJt2GjNNnaJL7xfibmlsnko0L6TASzGBNKKOs9vzs14In7xNvrXobTtZjtgH sJSo2PbGpDTHXv1G7wai =1F7p -----END PGP SIGNATURE----- -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security