Security

Posted Sep 1, 2014 16:43 UTC (Mon) by cyperpunks (subscriber, #39406)
In reply to: Poettering: Revisiting how we put together Linux systems by torquay
Parent article: Poettering: Revisiting how we put together Linux systems

There are some very, very good reasons for using a distribution which dont seems to be present in the blog.

Let's use the Heartbleed issue as an example.

To get fully protected after the bug, all work a distro user was required to do was to install the latest openssl package form the distro.

Now, in this new scheme of things, the user is forced to upgrade every single instance and check each for any possible Heartbleed issue.

The new scheme brings flexibility, however from a security viewpoint, it seems like a nightmare.

Security

Posted Sep 1, 2014 17:00 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

What you claim is true only if all apps are installed using distribution repositories. real world deployments often have ad hoc installations and what is being proposed might help with that pain.

Security

Posted Sep 1, 2014 17:26 UTC (Mon) by cyperpunks (subscriber, #39406) [Link] (2 responses)

Not if the ad hoc installed apps are using system libraries.

Security

Posted Sep 1, 2014 21:12 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Which they often don't. Instead ad-hoc installations tend to bundle the libraries because they want to be independent of the distribution.

Security

Posted Sep 2, 2014 9:52 UTC (Tue) by NAR (subscriber, #1313) [Link]

I did use a software that bundled the openssl library because they wanted to be independent of the distribution. Of course they failed, because a newer version of the same distribution had newer glibc with new bugs, so after an OS upgrade the software stopped working...

Security

Posted Sep 1, 2014 19:45 UTC (Mon) by Wol (subscriber, #4433) [Link] (3 responses)

> To get fully protected after the bug, all work a distro user was required to do was to install the latest openssl package form the distro.

For a non-distro user (or, like me, a gentoo user), all that was needed was to not switch on the broken functionality in the first place! The reports I've seen all said that - for most machines - heartbleed was functionality that wasn't wanted and should not have been enabled to start with.

Yes I know users "don't want" the hassle, but gentoo suits me fine. I switch things on if I need them. That *should* be the norm.

Cheers,
Wol

Security

Posted Sep 2, 2014 17:17 UTC (Tue) by rich0 (guest, #55509) [Link] (2 responses)

So, I run Gentoo, but I'm not sure I buy that argument. In this case the bug only occurred if TLS heartbeat was enabled. What if next time a bug only occurs if something you might not think you need is disabled?

I think you just got lucky, and running USE=-* has its own issues.

Security

Posted Sep 2, 2014 18:29 UTC (Tue) by Wol (subscriber, #4433) [Link]

Well, I gather one of the BIG reasons heartbleed was such a disaster was

(a) most people had it switched on
(b) most people weren't using it

That's a recipe for minimal testing and maximal problems.

Your scenario is where most people need the functionality, so I'm in a minority of not wanting or needing. I don't think that is anywhere near as likely (although I could be wrong ...)

Cheers,
Wol

Security

Posted Sep 4, 2014 19:30 UTC (Thu) by NightMonkey (subscriber, #23051) [Link]

Gentoo would at least have given you a chance to disable the offending subcomponent (in a managed way), had a fix from the OpenSSL camp not come quickly enough.

Security

Posted Sep 2, 2014 2:26 UTC (Tue) by raven667 (subscriber, #5198) [Link]

This actually isn't any different in the proposed scheme because the base of the proposed runtimes _are_ the existing distros, which each have to apply security updates to the shared libraries they ship, we are already living that nightmare.