[kbenson]

The last thing I want is to be manually rolling package updates for kernels. That's one of the reasons I use a distro in the first place, to offload testing to a dedicated team of people. If I was still interested in that, I would run Linux From Scratch again.

As soon as you've administered 10+ servers at the same time, your patience for variation from the norm and manual patch building goes way down.

Once you've administered 100+ servers at the same time, any thoughts of doing that go right out the window. along with the person that brought it up.

At that point, any changes are diffs applied to the original package (or a brand new package from scratch) that you put in your local repo. Kernels actually get updates fairly often, which means you either have a lot of work, or you ignore the non-essential updates. Neither are ideal.

[geofft]

Yes. Updated packages for this CVE are already out, and you can just `apt-get dist-upgrade && reboot`. Unless you're prepared to invest organizational effort in a kernel build process, the amount of security you gain from running a custom kernel, in exploits that don't affect you, is vastly outweighed by the amount of security you lose when an exploit does affect you and you have to get around to doing a local kernel build. Good luck if the person who usually does it is sick that day.

It's certainly possible to build infrastructure to automate compiling, testing, and pushing out a new kernel, but very few organizations are going to justify that much development effort just for security reasons. If you're already building your own kernels because you have other technical reasons for it, and therefore have already put this effort in, then yes, just turn off CONFIG_IP_DCCP and call it done.

[blockoperation]

I can see why it might be a burden when you're dealing with hundreds of servers, but on a personal machine, where the occasional disruption won't get you sacked, it's pretty straightforward (though I say this as someone who follows kernel development as a hobby and has the time to track down bugs).

[geofft]

On the other hand, for a personal machine, caring about local root exploits is almost certainly outside your threat model. You have a https://xkcd.com/1200/ architecture, where everything other than software updates is running as uid 1000. The things you actually care about, your emails, your IMs, your tax documents, etc., are all accessible to uid 1000. Any random malware you might download will run as uid 1000. root is honestly a less interesting target. And the non-root account runs sudo often enough that an attacker with access to your account can get to root with a bit of patience, anyway, no kernel exploits required.

I used to maintain a laptop with two user accounts, one of which I used for running sudo and doing important work, and one of which had the Flash and Java plugins enabled and was used for Pandora, YouTube, etc. It sorta worked, but it was a pain, and I eventually gave up on it. If you do have a setup like this, then caring about local root exploits starts to make a bit of sense.

I now have a Chromebook, which sandboxes any attacker-controlled executable code on the machine. If you actually care about the security of your personal computer, do that, or get Qubes or something—and just use the vendor's provided OS and keep it up-to-date.

[blockoperation]

Multiple accounts can be quite usable if you get the separation right. Separate uids for personal emails/banking and porn browsing should be a given, at least.

[kbenson]

At that point, why stop at separate uids and not just use separate virtual servers? It's a bit more costly in space and RAM (when running), but it's pretty good at reducing the attack surface. If you really want to be paranoid, restore from a snapshot every time you start the VM, and occasionally start it just to update it and create a new snapshot. Even if an attacker does get a local account, they have to do something useful with it before you close the virt, essentially destroying anything local they've set up.

[jlgaddis]

firejail [0] looks interesting, though I haven't played with it yet.

[0]: https://firejail.wordpress.com/