The state of the Linux kernel security (2020) | Hacker News Reader

The state of the Linux kernel security (2020)

github.com

125 pointsbelter27 comments

Towards the middle of the presentation, this seems like an indictment against stable/long term Linux distributions. Maybe Arch's philosophy of always tracking latest limits the attack surface by reducing the overhead of backporting security fixes?

The primary reason to use a stable/long term distribution is to avoid updates which break my workflow, not to avoid security holes. For Debian the most visible example of that is that in Debian Stable default repos you only have Firefox ESR, which helps avoid a lot of pain for the user. There are other examples, but nothing breaks my workflow as much as new Firefox releases.

Moreover, Debian Stable has a 24H security fix deadline, which voluntarily forces them to fix a lot of security holes pretty quickly.

Don't they back port security fixes to stable branch too? I'm a testing user, so I don't follow Stable's package updates very closely.

Most bugs that get backported to stable kernels only get backported if they are serious enough or have a CVE assigned to them. Many bugs with potential security implications go unfixed because of this.

Oh, OK. I learned something important today. Thanks a lot.

Yea, it's not just desktop either but having stable releases for server workloads is pretty much essential. If there's no need to update for any required feature in a later version then doing updates for the sake of it just creates churn and actually increases the risk of potential outages. Stable with backported fixes for security means that only updates for security need to be actioned.

I strictly run Debian Stable on my own servers but, they're low in numbers (office uses CentOS, because we need to), and I use unattended upgrades on these small servers. At the end of the day, I don't touch them unless I have to (because updates restart services most of the time anyway), but I understand your point completely.

I'm not against only back porting serious security fixes only (since both time and resources are limited, and a good trade-off is always the best choice). Just it did occurred to me that I didn't wrap my head around the details of this particular subject.

Yea, I used unattened-upgrades for everything not libc/kernel and then use the requires-restart stuff (you can do this on centos and debian based distros) just to make sure it's a bit more managed. Nowadays a lot more stuff I deploy is in immutable containers with health checks so tends to be less of a pain, but you trade that off in increase in complexity and overheads etc. Still have to reboot hypervisors too if not managed.

I feel this approach merely _accumulates_ breaking changes (breaking in the sense that they break your workflow, not that Firefox fails to start).

When you update Debian to a new release, you suddenly get a huge influx of changes: new Firefox, new DE, new bash, new kernel, new email client, etc. Everything gets updated at once.

It's likely that more than one thing will break your workflow, and you'll spend a significant amount of time dealing with all of those at once.

Arch just spreads that over time. Instead of having to deal with ALL of these things at once every 6 months (or every two years), I deal with tiny changes very often. It's very unlikely that both the kernel AND Firefox will have changes that affect me on the same day.

I also feel it's more sustainable to deal with small change once every couple of weeks, than huge changes twice a year. Arch is stable in that the changes per day ratio is constant over a long period of time, while's Debian is 0 changes for months, and then hundreds of changes at once.

There is such a lack of security in userspace, that I don’t think that any “mainstream” linux distro could be considered secured regardless of update policy.

Yes, this is one of the many reasons why I tend to prefer rolling release, gasp, even on servers. Instability is easier for me to deal with than out of date software with security holes.

I do think long term nix/guix will be the trend setters, but till then rolling release is where its at for some of us.

I also just have to say, once you get used to running the latest of everything, the pain of a more traditional distro becomes much more noticable.

One thing, all of this really makes me want to try gentoo again for a bit.

Video of presentation: https://youtu.be/PGwFyzh2KTA?list=PLVl2hFL_zAh-cAfx6y4k-fODf...

Thanks to Kees and all the people that have worked over at Kernsec. I've been watching on the mailing lists for some time now and it's been really fun to get an insight into the work that's been going on there.

Obligatory Rust comment: would it help reduce bugs if we replaced loads of janky C code with janky rust code?

Yes, but good luck getting much effort to happen. Microsoft has said for a few years[1] now that using rust would solve a majority of their kernel sec issues, but they haven't said much since. The work to do that much porting is probably harder and would introduce other bugs then fixing problems as they emerge.

[1]https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...

I think security architecture evolved a bit, so a simple rewrite is probably not worth it. Question is if more modern approaches are indeed better. Mobile devices convince me otherwise.

> Mobile devices convince me otherwise.

Why do you think so? We’ve never had such an easily accessible device used by so many people that routinely run untrusted code and is basically full of overly personal information and data. Yet we seldom hear security implications.

I’m no security researcher but recently taken a dive into the topic and the state of the art security research is with mobile OSs and iPhones and to a degree android (GrapheneOS itself) does a great job at it.

I measure the result. Mobile devices leak much more data compared to desktop, although that is also due to simple misbehavior of apps and some compromises that we talk about phones.

Mobile devices are packed with sensors in a way that desktops aren't. And of course it doesn't help that users generally want those sensor measurements to be accessible to the apps they use.

Well inacessible sensors are rather useless weight

Privacy != security

I disagree. Especially if these privacy violation happen without the explicit knowledge of the user.

In 2020 there were 304 publicly disclosed security defects in iOS of which 94 were severe [1] which means an average of 2 severe defects per week and 859 in Android of which 214 were severe which is an average of 4 severe defects per week.

These constitute fairly average years (within a factor of 2) so you can reasonably expect that a similar number of defects will be discovered in their currently shipping versions by the end of the year.

[1] https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

[2] https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

We would need a reference to compare it against so the data can be meaningful. Also, a patched before disclosure vulnerability is not the same as an actually exploited one. I would really be curious on what do you consider secure that has a similar complexity/attack surface and usage to phone OSs? Apple on the desktop comes close, and Windows does an okayish job, unfortunately Linux (userspace) is terrible security-wise.

There's definitely a movement to be more open to Rust, but I don't think you'll be seeing it replacing swathes of code anytime soon. Device drivers and such, maybe, but this be a long-tail if at all.

Yes, but that's of course a long-term, difficult project.

The stats in that presentation show a large proportion of the bugs being ones that Rust would address. So, yes, in principle.

Reply on news.ycombinator.com