Disables IPv6 via cmdline option for Focal

[conorsch]

Status

Ready for review

Description of Changes

Fixes #5807

Adds a Focal-only cmdline option for the boot to disable IPv6
functionality completely. Adds a config test to ensure no IPv6 addresses
are assigned.

Testing

• CI must pass on both Xenial & Focal
• On a Focal staging VM, run sudo ip addr and ensure you see no IPv6 addresses on any interface.

Deployment

Changes are Focal-specific, Xenial behavior remains unchanged.

[conorsch]

Marking WIP because I encountered the following error during local testing on Qubes staging:

    TASK [grsecurity : Check if reboot is required due to inactive grsecurity lock.] ***
    changed: [app-staging]
    changed: [mon-staging]
[WARNING]: flush_handlers task does not support when conditional
    included: /home/user/securedrop/install_files/ansible-base/tasks/reboot.yml for app-staging, mon-staging

    RUNNING HANDLER [common : Gracefully halt Qubes staging VM] ********************
    changed: [mon-staging -> localhost]
    changed: [app-staging -> localhost]

    RUNNING HANDLER [common : Boot Qubes staging VM] *******************************
    changed: [app-staging -> localhost]
    changed: [mon-staging -> localhost]

    TASK [grsecurity : Set sysctl flags for grsecurity.] ***************************
    changed: [mon-staging] => (item={'name': 'kernel.grsecurity.rwxmap_logging', 'value': '0'})
    changed: [mon-staging] => (item={'name': 'kernel.grsecurity.grsec_lock', 'value': '1'})
    changed: [mon-staging] => (item={'name': 'vm.heap_stack_gap', 'value': '1048576'})
    failed: [app-staging] (item={'name': 'kernel.grsecurity.rwxmap_logging', 'value': '0'}) => {"ansible_loop_var": "item", "item": {"name": "kernel.grsecurity.rwxmap_logging", "value": "0"}, "msg": "Data could not be sent to remote host \"10.137.0.50\". Make sure this host can be reached over ssh: ssh: connect to host 10.137.0.50 port 22: Connection timed out\r\n", "unreachable": true}
    failed: [app-staging] (item={'name': 'kernel.grsecurity.grsec_lock', 'value': '1'}) => {"ansible_loop_var": "item", "item": {"name": "kernel.grsecurity.grsec_lock", "value": "1"}, "msg": "Data could not be sent to remote host \"10.137.0.50\". Make sure this host can be reached over ssh: ssh: connect to host 10.137.0.50 port 22: No route to host\r\n", "unreachable": true}
    failed: [app-staging] (item={'name': 'vm.heap_stack_gap', 'value': '1048576'}) => {"ansible_loop_var": "item", "item": {"name": "vm.heap_stack_gap", "value": "1048576"}, "msg": "Data could not be sent to remote host \"10.137.0.50\". Make sure this host can be reached over ssh: ssh: connect to host 10.137.0.50 port 22: No route to host\r\n", "unreachable": true}
    fatal: [app-staging]: UNREACHABLE! => {"changed": false, "msg": "All items completed", "results": [{"ansible_loop_var": "item", "item": {"name": "kernel.grsecurity.rwxmap_logging", "value": "0"}, "msg": "Data could not be sent to remote host \"10.137.0.50\". Make sure this host can be reached over ssh: ssh: connect to host 10.137.0.50 port 22: Connection timed out\r\n", "unreachable": true}, {"ansible_loop_var": "item", "item": {"name": "kernel.grsecurity.grsec_lock", "value": "1"}, "msg": "Data could not be sent to remote host \"10.137.0.50\". Make sure this host can be reached over ssh: ssh: connect to host 10.137.0.50 port 22: No route to host\r\n", "unreachable": true}, {"ansible_loop_var": "item", "item": {"name": "vm.heap_stack_gap", "value": "1048576"}, "msg": "Data could not be sent to remote host \"10.137.0.50\". Make sure this host can be reached over ssh: ssh: connect to host 10.137.0.50 port 22: No route to host\r\n", "unreachable": true}]}

A reboot of the VM resolved, which seems to suggest an iptables ratelimit on SSH. Can't see how that's related, so more testing required.

[conorsch]

Updated the sysctl syntax to skip ipv6 settings under Focal, since disabling boot time means the associated sysctl tasks will fail. Waiting for CI to pass, then will mark ready.

[rmol]

Ah, I saw that same connection error on Qubes. Good. 😄

[conorsch]

Hmm, based on CI failure in https://app.circleci.com/pipelines/github/freedomofpress/securedrop/1982/workflows/4abc8b06-ffb1-4c22-a117-24a7d72ef407/jobs/51269, looks like the securedrop-grsec package in the apt-test repo is taking precedence over the locally built one for staging environments. That means the config added here isn't live in staging.

[rmol]

Ah, that's another error I saw but hadn't had time to dig into. reprepro is converting the last hyphen to an underscore, so apt-test's package sorts later, despite being the same version. Probably easiest to change the naming under build/.

[conorsch]

It looks to me like the package simply wasn't being held, so I've tacked on a commit to hold it and see if that resolves. The "last hyphen" you mention shouldn't matter in this context, since apt will still find it and pull it in. Let's see what CI thinks of that idea.

[rmol]

I just got through a clean Focal staging run on Qubes. No IPv6 addresses on any interface, app or mon.

I kicked CI in the hopes that it might be similarly happy.

[conorsch]

Thanks, @rmol. I'm definitely seeing the tests passing on Focal locally. To get CI happy, I just pushed another small diff to the package-hold logic that should resolve for Xenial, too:

 --- a/install_files/ansible-base/group_vars/all/securedrop
+++ b/install_files/ansible-base/group_vars/all/securedrop
@@ -45,3 +45,6 @@ securedrop_pkg_grsec_xenial:
 securedrop_pkg_grsec_focal:
   ver: "5.4.97"
   depends: "linux-image-5.4.97-grsec-securedrop,intel-microcode"
+
+# Mostly useful for local package installation
+grsec_version: "{{ securedrop_pkg_grsec_xenial.ver if securedrop_target_distribution == 'xenial' else securedrop_pkg_grsec_focal.ver }}"

CI running now.

[kushaldas]

This perl expression is causing the trouble.

[kushaldas]

This CI failure is valid:

5\.4\.97\-grsec\-securedrop$|^linux-.*-5\.4\.97\-grsec\-securedrop$|^kfreebsd-.*-5\.4\.97\-grsec\-securedrop$|^gnumach-.*-5\.4\.97\-grsec\-securedrop$|^.*-modules-5\.4\.97\-grsec\-securedrop$|^.*-kernel-5\.4\.97\-grsec\-securedrop$) regexp to find running kernel packages
Checking: securedrop-grsec ([<Origin component:'main' archive:'' origin:'SecureDrop' label:'' site:'apt-test.freedom.press' isTrusted:True>])
pkgs that look like they should be upgraded: securedrop-grsec
Get:1 https://apt-test.freedom.press focal/main amd64 linux-image-4.14.188-grsec-securedrop amd64 4.14.188-grsec-securedrop-1 [50.8 MB] 

not sure why.

[emkll]

not sure why.

The securedrop-grsec package is installed by both local debs and through apt-test, in the staging scenario. The test failure here might be related to holding the package in https://github.com/freedomofpress/securedrop/pull/5810/files#diff-8164feba234adc81cf7c91b9f402a0a90f3f7bc1983231168a61db05f56be279R10

The failing test (test_unattended_upgrades_functional) ensures all packages are up to date on the running system. The output of when a package is held (per the command above) might be different here and require the test to be updated, or perhaps the hold is not honored by unattended-upgrades ?

[conorsch]

Magnificent, so at least marking the package as held gets the relevant tests passing, so the boot option is enabled and IPv6 is fully disabled on Focal. That's good! Looking at the unattended-upgrades test failure locally. We mark all of the locally built packages in staging as held, so I'm surprised that securedrop-grsec is a problem. @rmol had a hypothesis in #5810 (comment) that's worth a closer look

[rmol]

@rmol had a hypothesis

Bzzzt. 🙂 You were right; that wasn't it. It's just the default preferences. With the local filenames matching apt-test and the hold reverted, apt still prefers installing from apt-test:

# apt-cache policy securedrop-grsec
securedrop-grsec:
  Installed: 5.4.97+focal
  Candidate: 5.4.97+focal
  Version table:
 *** 5.4.97+focal 500
        500 https://apt-test.freedom.press focal/main amd64 Packages
        100 /var/lib/dpkg/status

[conorsch]

Thanks for testing, @rmol! At least that's predictable: it seems the lack of a hold on that package would explain the behavior we're seeing nicely. I've got a potential fix (works locally, anyway) running over here: https://app.circleci.com/pipelines/github/freedomofpress/securedrop/2012/workflows/66426b84-4c72-451b-83f7-2e0a342653ab Didn't want to append here until I was sure that works, especially since you were looking into the problem, as well.

[conorsch]

Aye, we have fully green CI! https://app.circleci.com/pipelines/github/freedomofpress/securedrop/2012/workflows/66426b84-4c72-451b-83f7-2e0a342653ab I've pushed those same commits here, waiting on confirmation of green across the board.

[rmol]

Shouldn't this be {{ item}} now?

[conorsch]

Yes, fixing...

[conorsch]

@rmol Behold, CI is passing here. Thanks for your patience in passing this one back and forth. Mind giving it a final review prior to merge? This is the last PR we want in before we can cut the 1.8.0 branch (#5794).

[rmol]

Rebuilt staging, all good, no IPv6.