[ubuntu-cloud] [ec2] RFC: server-lucid-ec2-config: user-data configuration file

[Hedge Hog]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Tue, Jan 5, 2010 at 11:38 PM, Soren Hansen  wrote:
> On Tue, Jan 05, 2010 at 03:11:50AM -0800, Eric Hammond wrote:
>> We choose when to update our running systems, often after testing in
>> development and QA environments.  However, if systems are being fired
>> up automatically by Amazon's Auto Scaling or Spot Instances and those
>> instances upgrade themselves on boot, then package upgrades are forced
>> on you whether or not you have tested, unless you choose to use a
>> date-fixed apt mirror like RightScale offers.
>
> If Ubuntu were ever to offer date-fixed repositories, I would personally
> consider that having declared complete bankruptcy on our SRU and
> security update policies and procedures. If we don't even trust our own
> process for these updates, and acknowledge the need for date-fixed
> repositories, we've lost. If we discover shortcomings in these
> processes, we need to fix them, not offer ways to circumvent them.
>
> Furthermore, even the smallest delays in applying security updates means
> a window of opportunity for an attacker. I consider it a critical

People that concerned about such vulnerable components can/should
secure with something like fwknop - my understanding is such software
protects against 0th day attacks.  Ideally they'd seperate such a
component and isolate it behind fwknop.
If they are not that concerned, or can't implement that architecture
then /maybe/ getting Canonical's N updates asap is worth the (v.small)
probability one or more updates brings in some problem.  But that is a
big maybe.

It is worth reiterating when calculating expected losses/costs:  very
small probability times extremely large state value = non-negligible
cost/loss.  Its not the prob that defines the size of a 'risk', its
jointly the size of the prob /and/ the size of the payoff.
Soren seems to assume the potential losses from a security
vulnerability outweighs the potential losses from a introducing a
subtle bug.
My opionion is the opposite - but it is just an opinion.
Not every machine in the cloud will hold millions of customers credit
card details.

Canaonical can make an effort to drive down the probablility of a
'bad-update' event.
They can't do anything (without sending in their consultants) about
the size of the state variable.
So small probablility != small potential loss.
Long-winded way of saying: Yes. Try to make things secure and bug
free.  No. It is not axiomatic that the benefits of speedy upgardes
outweigh the costs - until you get the probability to zero ;)

Until then I'm with Eric.  I don't want things updating automagically
by default, but I would like that option from time-to-time, on a
case-by-case basis.

another 2c.

> feature for Ubuntu that our users should feel comfortable applying our
> security updates without much scrutiny.
>
> --
> Soren Hansen                 |
> Lead virtualisation engineer | Ubuntu Server Team
> Canonical Ltd.               | http://www.ubuntu.com/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAktDMr0ACgkQonjfXui9pONrxQCfaLoOO65QbgTO8iaoYuH6NN/1
> /wcAoLKxElxqlMT6YYsMV1FNE3DZz9y+
> =jkED
> -----END PGP SIGNATURE-----
>
> --
> Ubuntu-ec2 mailing list
> Ubuntu-ec2 at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-ec2
>
>
- --
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
  Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)

iEYEARECAAYFAktEkBQACgkQL/DTCig+Nhc3QACdEGOskN4k6rV/8L7BoNCmOQi7
/qoAn0Xc3AY+PZpLzRAo6+zwszy073Lc
=FRm6
-----END PGP SIGNATURE-----