Bug #10831

Update nopersistent boot parameter

Added by intrigeri 2015-12-31 10:36:36 . Updated 2016-01-27 13:31:57 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Persistence
Target version:
Tails_2.0
Start date:
2015-12-31
Due date:
% Done:

100%

Feature Branch:
bugfix/persistence-fixes-for-2.0-take1
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Apparently, since live-boot (3.0~a27-1) and this commit:

commit 4e54d60d7f69ae3441e519e5611bd7ea48a8be19
Author: Daniel Baumann <daniel@debian.org>
Date:   Sun Apr 8 18:29:45 2012 +0200

    Using 'persistence' (noun) rather than 'persistent' (adjective/adverb) everywhere.

… we should use nopersistence instead of nopersistent on the kernel command line.

Strangely, commit:db4e9230ebf36cbe6fa0f451a90d29d9ce4d7ec3 updates the design doc while the code is unchanged. Too bad we didn’t have an automated test for the way live-boot handles persistence in the initramfs.

This may has security implications, to be confirmed (the fact we’re passing live-media=removable might help quite a bit).

Subtasks

History

#1 Updated by intrigeri 2015-12-31 10:37:49

  • Description updated

#2 Updated by intrigeri 2016-01-01 03:08:13

  • Description updated

#3 Updated by intrigeri 2016-01-01 03:27:26

  • Status changed from Confirmed to In Progress
  • Priority changed from High to Normal
  • % Done changed from 0 to 10
  • Private changed from Yes to No
  • Feature Branch set to bugfix/10831-update-nopersistent-boot-parameter

Thanks to live-media=removable, the impact of this mistake is that indeed live-boot looks for persistent volumes (for the rootfs and home directory) on removable storage media at boot. This is useless and suboptimal, and might slow down the boot a bit, but at least it does not break our design goal of not trusting internal hard drives: we’re instructing live-boot to look for the root SquashFS on any plugged removable storage device, that are considered to be trusted, so letting it look for overlays there as well does not break our current security model (if we had Feature #7475 already, this analysis would be different).

On the test suite side: we’re already testing that live-media=removable is effective when it comes to looking for the root squashfs. This parameter bypasses persistence/@nopersistence, so I don't think we need to add a specific test case. Now, perhaps it would be useful as a regression test, to let us notice e.g. any regression in the handling of live-media=removable@ => kytv, this may be a good candidate for your “write regression tests” mission; keep in mind that we’re talking about live-boot’s regular persistence features here, that happen at initramfs time, not the weird way we’re using them for TailsData later in the boot process. I’ll let you create the corresponding ticket.

#4 Updated by intrigeri 2016-01-01 06:11:24

  • Assignee changed from intrigeri to anonym
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

I’ll do a test suite run to check that the proposed persistent-related changes don’t break anything, but I’d like to do it only once so I’ll work on Bug #10809 first, so here you go.

#5 Updated by intrigeri 2016-01-01 11:04:35

  • Feature Branch changed from bugfix/10831-update-nopersistent-boot-parameter to bugfix/persistence-fixes-for-2.0-take1

#6 Updated by anonym 2016-01-03 13:47:18

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:aeee0d93b4ae60cd187417659a4821fb2402cba0.

#7 Updated by anonym 2016-01-03 13:50:41

  • Assignee deleted (anonym)

> Thanks to live-media=removable, the impact of this mistake is that indeed live-boot looks for persistent volumes (for the rootfs and home directory) on removable storage media at boot. This is useless and suboptimal, and might slow down the boot a bit, but at least it does not break our design goal of not trusting internal hard drives: we’re instructing live-boot to look for the root SquashFS on any plugged removable storage device, that are considered to be trusted, so letting it look for overlays there as well does not break our current security model (if we had Feature #7475 already, this analysis would be different).

Thanks for spelling out the analysis clearly. I agree that there was no harm done. Phew!

#8 Updated by anonym 2016-01-03 13:54:37

  • QA Check changed from Ready for QA to Pass

#9 Updated by intrigeri 2016-01-03 14:23:06

> Thanks for spelling out the analysis clearly.

Well, initially I started to write it thinking it would end up in a security advisory. Thankfully, that’s not needed in the end.

#10 Updated by anonym 2016-01-27 13:31:57

  • Status changed from Fix committed to Resolved