[HN Gopher] The state of the Linux kernel security (2020)
       ___________________________________________________________________
        
       The state of the Linux kernel security (2020)
        
       Author : belter
       Score  : 121 points
       Date   : 2021-06-15 10:02 UTC (12 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | candiddevmike wrote:
       | 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?
        
         | yakubin wrote:
         | 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.
        
           | bayindirh wrote:
           | 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.
        
             | 0xC0ncord wrote:
             | 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.
        
               | bayindirh wrote:
               | Oh, OK. I learned something important today. Thanks a
               | lot.
        
               | _joel wrote:
               | 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.
        
               | bayindirh wrote:
               | 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.
        
               | _joel wrote:
               | 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.
        
         | arminiusreturns wrote:
         | 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.
        
         | kaba0 wrote:
         | 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.
        
       | _joel wrote:
       | 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.
        
       | ClumsyPilot wrote:
       | Obligatory Rust comment: would it help reduce bugs if we replaced
       | loads of janky C code with janky rust code?
        
         | raxxorrax wrote:
         | 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.
        
           | kaba0 wrote:
           | > 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.
        
             | Veserv wrote:
             | 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=...
        
               | kaba0 wrote:
               | 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.
        
             | raxxorrax wrote:
             | 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.
        
               | seoaeu wrote:
               | 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.
        
               | kaba0 wrote:
               | Privacy != security
        
         | _joel wrote:
         | 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.
        
         | pcwalton wrote:
         | Yes, but that's of course a long-term, difficult project.
        
         | usename_Here wrote:
         | 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...
        
       | amarshall wrote:
       | Video of presentation:
       | https://youtu.be/PGwFyzh2KTA?list=PLVl2hFL_zAh-cAfx6y4k-fODf...
        
       ___________________________________________________________________
       (page generated 2021-06-15 23:02 UTC)