Trouble at Linux Mint — and beyond [LWN.net]

Trouble at Linux Mint — and beyond

Posted Feb 25, 2016 7:02 UTC (Thu) by isido (subscriber, #6976)
Parent article: Trouble at Linux Mint — and beyond

A very good article! I don't know what would be a way forward to fix the current semi-broken (securitywise) distribution model - this would seem to be a very hard problem.

One solution might be to move a bit towards to BSD-like model with OS core maintained by the distribution and relying more or less on the upstream to keep the software secure. I don't know if this would be actually a good solution - it would move the responsibility from the distribution maintainers to users and upstream.

Also, I'm not sure if rolling distributions á la Arch are stable enough for all purposes.

One thing I'm fairly certain though - in a couple years, dockerized applications with outdated dependencies will provide a nice new attack vector into our systems.

to post comments

Trouble at Linux Mint — and beyond

Posted Feb 25, 2016 7:21 UTC (Thu) by mjthayer (guest, #39183) [Link]

> One solution might be to move a bit towards to BSD-like model with OS core maintained by the distribution and relying more or less on the upstream to keep the software secure. I don't know if this would be actually a good solution - it would move the responsibility from the distribution maintainers to users and upstream.

I am obviously biased here, as I work at a project which "[tries] to get users to install their software directly", but linking to the upstream's download infrastructure and spending the effort which did go to maintaining packages on evaluating upstream's security might be a solution.

Trouble at Linux Mint — and beyond

Posted Feb 25, 2016 10:31 UTC (Thu) by aleXXX (subscriber, #2742) [Link]

> One solution might be to move a bit towards to BSD-like model with OS core maintained by the distribution and
>relying more or less on the upstream to keep the software secure. I don't know if this would be actually a good
> solution - it would move the responsibility from the distribution maintainers to users and upstream.

there are only a handful of BSDs, maybe it would indeed be better if the number of Linux distributions would shrink instead of grow, so the work would be, at least potentially, a bit more concentrated and not spread too thin.

Trouble at Linux Mint — and beyond

Posted Feb 25, 2016 12:56 UTC (Thu) by pabs (subscriber, #43278) [Link] (8 responses)

Do upstreams in general care more about security than the distros?

Trouble at Linux Mint — and beyond

Posted Feb 25, 2016 14:00 UTC (Thu) by jospoortvliet (guest, #33164) [Link] (2 responses)

In general? No idea. Depends on the upstream, I suppose. I'd expect projects building web apps to care a fair bit, especially if there's a business behind it - customer pressure and all that. I know we at ownCloud do a decent job... No idea about others, to be honest.

Trouble at Linux Mint — and beyond

Posted Feb 25, 2016 16:25 UTC (Thu) by misc (subscriber, #73730) [Link]

Caring about security can mean differents things. Is "publishing a announce" caring, or is "backporting the fix to a stable release" caring ? One of the main interest of using a distribution is the coordination, and if the model for security is "upgrade to latest version", it might not work that well in practice (mostly because some upstream are also platform for plugins and/or have unexpressed dependencies on the protocol with others components).

There is a reason why the model of Gentoo upgrade is not that widely used in the industry, even if CD/CI and new stuff permitting to revert (such as docker/rkt, ostree, snappy, or just immutable server) might change that.

Business depending on a web application might also have incentives to not offer a free version for a too long time, since some might sell a entreprise version supported for a longer time (even if that's at least better than the alternative of making a opencore model such as newer companies try to do, such as docker and docker datacenter, or beegfs with a strange opensource license)

I have been told that the LF have created a checklist regarding security, which might be a starting point for evalutating a upstream for suitability. having dealt with various upstream for reporting CVE, I must say that while I do not have a set big enough to get any definite conclusion, I was not impressed by how most of them handle security.

Few peoples know how to get a CVE, few seems to care getting one before publishing the patch (or even after), and one vendor took even 2 months to say "there is no security problem" issue, stance that was reverted once I posted publically to get feedback from others (and that's why "responsible disclosure" folks can't have nice things).

At the same time, dealing with distribution security team was a much nicer experience, mostly because they deal with more security issue, so they have likely more experience dealing with it. Maybe some kind of federation of upstream project security could work. 1 single point of contact for various upstreams, able to decide if a security bug is a security bug or not, able to contact the right person using the right medium, following a published process, etc.

And upstream should have to follow some charter to be part of the group.

That's maybe something that could convince me (as a packager, ex-distributor and current sysadmin) that upstream would provides the support I would find acceptable.

Of course, better understanding with the constraint of their downstream (and of the users of the downstream, cause distro do not have rules for the fun of having them) could help a lot. But since there is always a new set of upstream, and each starting by thinking "we know better", that's a never ending task.

Trouble at Linux Mint — and beyond

Posted Feb 27, 2016 5:20 UTC (Sat) by pabs (subscriber, #43278) [Link]

How do you track security issues (CVEs and otherwise) in the ownCloud VMs that are published?

How do users of those VMs get (for example) glibc security fixes?

Trouble at Linux Mint — and beyond

Posted Feb 25, 2016 16:23 UTC (Thu) by khim (subscriber, #9252) [Link] (4 responses)

Of course, no. But then distribution model is broken beyond repair anyway. There are constant bickering about bundled libraries, but the whole discussion is so bizzare it's not even funny.

Sure, if some popular library is updated and project which uses it does not issue a new version then you vulnerable. But are you protected if said project is changed to use library which is system-provided and thus updated? No, of course not: if project does not care about security enough to replace the library they depend upon then what chance is there that they would fix bugs in their own code? Or do you really believe that overworked distribution packagers could actually find time to do an actual review for the code of the software they are packaging?

Distributions were born to solve one simple problem: slow internet gave no way to easily download large packages and small HDDs needed shared libraries to save space. That's it. We should stop pretending that they are solving any other problems - and the problems of slow Internet access and small HDDs are largely behind us, too.

Distributions in their current form are part of problem, not a solution.

Trouble at Linux Mint — and beyond

Posted Feb 27, 2016 5:22 UTC (Sat) by pabs (subscriber, #43278) [Link] (1 responses)

Are you manually downloading, compiling and installing upstream projects like Linux, glibc, PHP and ownCloud instead of using a distribution?

Trouble at Linux Mint — and beyond

Posted Mar 1, 2016 11:04 UTC (Tue) by nix (subscriber, #2304) [Link]

I do! But unlike khim I recognize that I'm a bit of a lunatic and that what everyone else, particularly people looking for security, should do is use a distro to let the trouble off them and to avoid wasting time. (My network-exposed and sensitive boxes run Debian stable, though with glibc replaced to get my stack-protector patches. I'm *so* looking forward to not having to do that last bit.)

I don't do this because of security -- that's a ridiculous stance. I do this because I'm a control freak and hate changes in my working environment and don't want anything to change unless I changed it, and because I want to know the interrelationships and build trickeries of every package I run. I'd now say "because it's been useful in my job so often", which is true, only that doesn't explain why I started doing it fifteen years before I worked for a Linux distributor. The correct explanation is "because it's a habit and a really silly hobby", kind of like stamp collecting with packages. It is not a security benefit.

Trouble at Linux Mint — and beyond

Posted Feb 27, 2016 14:52 UTC (Sat) by lsl (subscriber, #86508) [Link]

> Distributions were born to solve one simple problem: slow internet gave no way to easily download large packages and small HDDs needed shared libraries to save space. That's it.

Nope. What pabs said, really. Distributions do a lot of work so you don't have to.

There's maybe a dozen of packages where my needs are special enough that I'm not getting them from my distro, directly tracking upstream instead.

Some of them are (intended to be) temporary and I'm working towards being able to just use the distro packages. Why? Because tracking those projects takes time. I can only afford that for a small set of packages I care deeply about. Doing it for all the software on even my personal machines is simply not realistic - that'd be a full-time job.

This is what distros provide to you.

Trouble at Linux Mint — and beyond

Posted Feb 28, 2016 23:59 UTC (Sun) by thoeme (subscriber, #2871) [Link]

>Distributions were born to solve one >simple problem: slow internet gave no >way to easily download large >packages and small HDDs needed >shared libraries to save space.
That's way too short sigthend: my distribution gives me a fully consistent linux experience on my workstation, and I very seldomly leave this comfort zone because of the simple fact that *they* know better than me what to fix and what to leave alone. If there are problems, I report them and wait for the fix from my distro, trying to temporarily work around the problem (like pulling problemeous hardware) instead of spending hours to try to ducktape the problem myself.... which seldom works anyway.
So in that light, the distribution *is* my upstream and I care less about the project itself.