Project

General

Profile

Bug #12266

Write release notes for 2.11

Added by anonym over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
02/25/2017
Due date:
% Done:

100%

Feature Branch:
spriver:web/tails-2.11-release-notes
Type of work:
End-user documentation
Blueprint:
Starter:
Affected tool:

Description

They should announce the removal of I2P in Tails 2.12.


Related issues

Blocks Tails - Feature #12265: Publicly announce the removal of I2P Resolved 02/28/2017

History

#1 Updated by anonym over 2 years ago

#2 Updated by anonym over 2 years ago

  • Assignee set to sajolida

Your availability for these jobs, that you normally do, is not clear to me. Will you be able to do it or should I look for someone else (or perhaps even try it myself!)?

#3 Updated by intrigeri over 2 years ago

[…] or should I look for someone else (or perhaps even try it myself!)?

If help is needed, I believe that spriver and/or I are in a better position than you to do tech writing :)

#4 Updated by anonym over 2 years ago

Ok, so if sajolida do not do this, does anyone of you, intrigeri and spriver, volunteer as a backup?

#5 Updated by spriver over 2 years ago

anonym wrote:

Ok, so if sajolida do not do this, does anyone of you, intrigeri and spriver, volunteer as a backup?

I never wrote release notes before, but I can try do so (: (at least I can help with reviewing) I should have plenty of time around the release.

#6 Updated by intrigeri over 2 years ago

Great, spriver! IIRC we have doc wrt. how to write release notes. I should be able to review your work, but it'll depend on timing.

  • anonym, when do you expect the changelog to be drafted?
  • Based on the above: spriver, when do you expect you'll have draft release notes?

#7 Updated by spriver over 2 years ago

Indeed, there is doc and a template for creating the release notes.
I'll have time this weekend to write a draft wrt. removing I2P. AFAIK, I can do the rest of the release notes soonest when the changelog is ready, right?

#8 Updated by intrigeri over 2 years ago

  • Assignee changed from sajolida to spriver

I'll have time this weekend to write a draft wrt. removing I2P.

Great! Note that feature/12271-i2p-removal-notification (that I've just merged into stable) introduces some text that could be reused.

AFAIK, I can do the rest of the release notes soonest when the changelog is ready, right?

Yes.

#9 Updated by sajolida over 2 years ago

The release is scheduled on the first day I'll be at IFF. I could be
able to write the release notes on Monday while travelling there.
Otherwise, I'm happy to let spriver work on that!

#10 Updated by anonym over 2 years ago

intrigeri wrote:

  • anonym, when do you expect the changelog to be drafted?

Normally this happens on Monday, since that's when I follow release_process.mdwn, and the changelog generation is part of it. I could do it earlier, upon request (so if you want it, spriver, just let me know).

spriver wrote:

I'll have time this weekend to write a draft wrt. removing I2P.

I2P will be removed in Tails 2.12, not in 2.11!

AFAIK, I can do the rest of the release notes soonest when the changelog is ready, right?

Yes, but if you want a partial changelog earlier, like I said, just ask.

#11 Updated by intrigeri over 2 years ago

  • Assignee changed from spriver to anonym
  • QA Check set to Info Needed

It seems that 442a293d896076a1a8242d8d4f3320dc016495bb fixes a serious security issue that's been present since we introduced MAC spoofing. Right? I would like to see a minimal analysis of the impact, that we can translate into the security advisory against 2.10 (IMO it's our duty to communicate clearly when we discover flaws in protections we were trying to offer).

I'll focus on the network drivers blacklist here, assuming that the other blacklisted modules are no big deal (but please double-check). So, in 2.10:

  • Can these modules be auto-loaded by the kernel during the boot process? Or only later when I plug a new network adapter later on?
  • What exact situations are affected? I guess at least the offline mode, and the MAC spoofing failure safety net. Plus maybe some more depending on the question above. Anything else?
  • What's the impact given the other mitigations we have in place? IOW, are the other safety nets we have enough to:
    • guarantee that no IP network connection will be set up in offline mode / when MAC spoofing fails? (of course this says nothing about lower-level things that this very blacklist scheme was meant to protect against, e.g. drivers sending packets themselves, before the MAC is spoofed)
    • mitigate the impact of security issues in blacklisted modules, that could potentially allow an adversary who got arbitrary code exec as amnesia to escalate to root?

(If I were mean, I would mention that problem in the "Tails' MAC 'leak prevention' question" thread, where I proposed a while ago to remove the blacklist approach :P)

#12 Updated by anonym over 2 years ago

intrigeri wrote:

It seems that 442a293d896076a1a8242d8d4f3320dc016495bb fixes a serious security issue that's been present since we introduced MAC spoofing. Right?

tl;dr: I don't think there has been a security issue here.

It seems blacklist MODULE is enough to block MODULE from automatically loading when plugged, since udev ("usually") runs modprobe with the --use-blacklist option (see man 8 modprobe). That is in contrast to e.g. opening a DCCP socket, which will autoload the dccp module. In other words, udev respects blacklist at all times, but the kernel's auto-loading mechanism does not (which makes sense, since it has no concept of /etc/modprobe.d).

I would like to see a minimal analysis of the impact, that we can translate into the security advisory against 2.10 (IMO it's our duty to communicate clearly when we discover flaws in protections we were trying to offer).

I'll focus on the network drivers blacklist here, assuming that the other blacklisted modules are no big deal (but please double-check). So, in 2.10:

  • Can these modules be auto-loaded by the kernel during the boot process? Or only later when I plug a new network adapter later on?

For the reason I detailed above, I don't think the blacklisted network modules can be automatically loaded at all. I implemented an automated test (see attached patch) which seems to confirm this (I checked out the 2.10 tag, applied the patch, and ran against the 2.10 ISO). I'd appreciate if someone with access to a real USB dongle could give it a shot on real hardware. Any one?

If I am correct I think all your other points irrelevant, so let's only look at them if someone manages to contradict me (e.g. with a test on real hardware).

#13 Updated by intrigeri over 2 years ago

tl;dr: I don't think there has been a security issue here.

Good. In other words, the commit we're discussing was "just in case we're missing something else that could go wrong", right?

#14 Updated by anonym over 2 years ago

intrigeri wrote:

tl;dr: I don't think there has been a security issue here.

Good. In other words, the commit we're discussing was "just in case we're missing something else that could go wrong", right?

It was for completeness and consistency since that's what we must do for e.g. the dccp module. TBH the security angle didn't occur to me; I didn't know udev respects blacklist, but I did carefully test plugging a USB dongle with a blacklisted module when I wrote this code for the MAC spoofing feature and it worked then.

Any way, case closed!

#15 Updated by anonym over 2 years ago

I've pushed the 2.11 changelog to the stable branch.

#16 Updated by spriver over 2 years ago

  • Assignee changed from spriver to anonym
  • QA Check set to Info Needed
  • Feature Branch set to spriver:web/tails-2.11-release-notes

I pushed a first draft of the release notes. I don't have the the 'Details' section of the security holes news populated so far, as I don't know if I have to search manually for every single fixed CVE from the security fixes in debian/changelog.

#17 Updated by anonym over 2 years ago

  • Assignee changed from anonym to spriver
  • QA Check changed from Info Needed to Dev Needed

spriver wrote:

I pushed a first draft of the release notes. I don't have the the 'Details' section of the security holes news populated so far, as I don't know if I have to search manually for every single fixed CVE from the security fixes in debian/changelog.

Yes, you have to do it manually and I haven't automated this since one essentially has to read the DSAs any way to make sure everything is correct, and while doing so I save the (package, DSA) pair in a convenient manner for writing the security notice later. It could be automated, I'm sure, but I bet it will be complex and possibly error prone.

Any way, your security notice looks good, except for linux. See: https://www.debian.org/security/2017/dsa-3791. As you can see, it says "these problems have been fixed in version 3.16.39-1+deb8u1", which we are not using. This DSA is from 2017-02-22, but the linux version we use is (ignoring a few minor releases which doesn't add much) from 2016-12-16, so it's highly unlikely all the issues from the DSA are fixed. In this instance we should only reference CVE-2017-6074 as fixed for linux.

This, and a few other issues (also in the release notes) are fixed in the web/tails-2.11-release-notes branch -- please merge it into yours, and let me know when you are done!

#18 Updated by spriver over 2 years ago

  • Assignee changed from spriver to anonym
  • QA Check changed from Dev Needed to Ready for QA

Thanks for your changes, sorry that I did not look too exactly at the Linux CVE. I made two minor additional changes and pushed them.

Twitter draft: Tails 2.11 is out: https://tails.boum.org/news/version_2.11.

#19 Updated by anonym over 2 years ago

  • Status changed from Confirmed to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 0 to 100
  • QA Check changed from Ready for QA to Pass

Great job, spriver! Your words shall be read by thousands of people! :)

#20 Updated by anonym over 2 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF