Feature #16391

Experiment with migrating to hardening-runtime

Added by intrigeri 2019-01-26 14:54:56 . Updated 2020-04-15 13:44:27 .

Status:
Confirmed
Priority:
Low
Assignee:
Category:
Target version:
Start date:
2019-01-26
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

hardening-runtime partly overlaps with hardening we’ve been implementing and maintaining as part as our delta with Debian for years. It would be sweet to check whether we could replace some of our custom stuff with this package. And then we can contribute improvements there and everyone benefits from them :)

Subtasks

History

#1 Updated by intrigeri 2020-03-09 17:53:22

  • Status changed from Confirmed to Needs Validation

I’ve looked a little bit into the package and indeed, there’s quite some overlap indeed:

… and some new things we don’t have: /proc and /sys hardening (https://salsa.debian.org/corsac/hardening-runtime/-/tree/debian/master/debian/permissions), which looks like good defense in depth if it breaks nothing for us, and remains that way; otherwise maintaining a delta will be annoying.

Then I’ve thought a little bit more about how what kind of trade-off we could find, between:

  • sharing our work: we have a commitment to contributing upstream when feasible
  • benefiting from the work done collaboratively in Debian and KSPP
  • enabling new hardening features without waiting for the next Debian stable: we could install hardening-runtime from sid, but it feels risky wrt. the next bullet point; but if we install it from stable, our users don’t benefit from improvements implemented in hardening-runtime (and in turn, our incentive to contribute there gets lower)
  • avoiding breakage popping up in Tails in an uncontrolled manner: we could install hardening-runtime from sid but a new setting enabled there could break stuff; e.g. when the RM freezes APT snapshots for a RC, we may get a newer hardening-runtime, and evaluating the impact adds to their workload in the middle of the critical path to the release, and increases risk; personally I prefer to have a bit more control on when we enable new kernel hardening settings

Here’s the best trade-off I could think of:

  • We install hardening-runtime from stable, and drop our settings that it makes redundant.
  • Day-to-day operations: we keep enabling new hardening settings as they land, and when we do so, we also send a MR to hardening-runtime
  • When we upgrade to the next version of Debian: we get a new version of hardening-runtime and we can drop the settings we’ve added via our delta since the last Debian stable, that it makes redundant. We need to track this somehow otherwise we’ll forget about it and we’ll gain nothing.

At this point, I think the benefits for Tails are not worth the extra effort and complexity. And given most of our settings come straight from a well-known place (https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), I won’t feel bad with not sharing “our” work with the world.

If you disagree with my conclusions, let’s talk.

#2 Updated by intrigeri 2020-03-09 17:53:53

  • Assignee deleted (intrigeri)

#3 Updated by anonym 2020-04-15 11:28:02

intrigeri wrote:
> * avoiding breakage popping up in Tails in an uncontrolled manner: we could install hardening-runtime from sid but a new setting enabled there could break stuff; e.g. when the RM freezes APT snapshots for a RC, we may get a newer hardening-runtime, and evaluating the impact adds to their workload in the middle of the critical path to the release, and increases risk; personally I prefer to have a bit more control on when we enable new kernel hardening settings

What if we freeze the hardening-runtime package we install from Sid by uploading it to our APT repo, and handle each upgrade manually, with proper QA? It could be something we do before each major release’s RC, so we get some testing in the wild and have the possibility to revert before the final release if issues are discovered. This seems pretty much like exactly what we want if we want to upgrade hardening-runtime more often than when updating to the next Debian.

#4 Updated by intrigeri 2020-04-15 13:39:14

> What if we freeze the hardening-runtime package we install from Sid by uploading it to our APT repo, and handle each upgrade manually, with proper QA?

I’m glad you put some thought into it :)

I think your proposal would work fine. What I’m doing below is to try to determine if it’s worth the effort.

Compared to what I called previously “the best trade-off I could think of”, that I thought was not worth the extra effort and complexity, it sounds like this proposal:

  • Requires roughly the same amount of technical work, but split into ~4× smaller chunks (~twice a year instead of once every 2 years). I suppose that’s mostly a good point.
  • Has 4× overhead (tracking, testing, reviewing, merging). That’s a clear drawback to me, in particular wrt. how FT is currently operating wrt. smallish, recurring tasks, that have high overhead, and look like grunt work.
  • Increases our incentive to actually send MRs to hardening-runtime, which is great.

Just like the best idea I could come up with myself, I doubt it’s worth the extra effort and complexity, but I’m ready to be proven wrong by reality and I won’t stand in the way if folks want to make it happen.

I’ll therefore leave this issue open and will adjust metadata accordingly.

#5 Updated by intrigeri 2020-04-15 13:44:27

  • Subject changed from Consider migrating to hardening-runtime to Experiment with migrating to hardening-runtime
  • Status changed from Needs Validation to Confirmed