Project

General

Profile

Feature #17178

Re-include metadata analysis tools

Added by huertanix 24 days ago. Updated about 7 hours ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

It appears that pdf-redact-tools was removed in #15291. Although this and other tools used for metadata analysis can be installed on Tails with an internet-connected computer, there's some particularities with SecureDrop's airgap requirement that make the addition of new software much more challenging and largely impractical. It would be great to have the tools mentioned in Freedom of the Press Foundation's guide on metadata (https://freedom.press/training/everything-you-wanted-know-about-media-metadata-were-afraid-ask/) installed by default. This would include:

  • pdf-redact-tools
  • tesseract-ocr
  • ffmpeg

History

#1 Updated by sajolida 17 days ago

  • Assignee set to huertanix

Good to see you again @huertanix!

While working on the Additional Software feature last year, having them work offline was part of our goals. See https://tails.boum.org/contribute/design/additional_software_packages/: "Ensure packages are installed even offline".

I think that were considering that it would be fine for a Tails USB stick used offline to still be plugged to the Internet when being configured, then restarted and used only offline.

To study the impact of your request a bit more in details, I created a branch that adds pdf-redact-tools, tesseract-ocr, and ffmpeg to see how many extra megas they would add to the ISO image. The ISO image will be available on https://nightly.tails.boum.org/build_Tails_ISO_feature-17178-metadata-tools/ after some time.

I'd also like to understand better what makes the current implementation of Additional Software impractical in your case (because maybe we can fix that instead!):

  • What are the airgap requirements of Secure Drop that make it impractical?
  • How are you dealing with this right now?

#3 Updated by huertanix 15 days ago

sajolida wrote:

Good to see you again @huertanix!

Good to see you too!

I'd also like to understand better what makes the current implementation of Additional Software impractical in your case (because maybe we can fix that instead!):

  • What are the airgap requirements of Secure Drop that make it impractical?
  • How are you dealing with this right now?

In this case, the airgap architecture we use requires a Tails drive that is only connected to a machine which has never or ever will connect to the internet, so unfortunately a temporary connection to the internet for the download is not an option.

At the moment, we have a pre-Additional Software tool process that involves copying apt cache files via clean USB drive to the airgap machine and using dpkg to install things one thing at a time. However, it would be amazing if the Additional Software tool had the ability to make this process easier so that it could export the packages, dependencies etc needed into one big file that can then be sneakernet transferred to the airgap and imported on the airgap's Additional Software tool. Or something along those line.

#4 Updated by sajolida 9 days ago

What I understand from your scheme (and my relative knowledge of Debian) is that you end up running packages (and their installation scripts) that were downloaded from elsewhere as root on your airgaped Tails.

I understand that you're using this airgap scheme to protect from potentially very powerful adversaries that could corrupt the airgaped Tails. But how do you prevent such a powerful adversary to infect the packages that you copy to the airgaped Tails? I'm assuming here that the OpenPGP verification of Debian happens at the time APT downloads the packages but not when packages are installed using dpkg, but maybe I got this wrong.

I'm asking this because, in the end, we might realize that it's not worth building a tool to install Additional Software over sneakernet. If so, then maybe the only possible answer to your problem would be to never run as root anything that's not included in Vanilla Tails.

What are the packages that you install this way? pdf-redact-tools, tesseract-ocr, and ffmpeg? Anything else?

#5 Updated by huertanix 9 days ago

sajolida wrote:

I understand that you're using this airgap scheme to protect from potentially very powerful adversaries that could corrupt the airgaped Tails. But how do you prevent such a powerful adversary to infect the packages that you copy to the airgaped Tails? I'm assuming here that the OpenPGP verification of Debian happens at the time APT downloads the packages but not when packages are installed using dpkg, but maybe I got this wrong.

I also think the PGP signature verification happens upon download rather than install. I may be wrong but if I'm thinking this through correctly, an adversary would have to seize the package maintainer's PGP private key to create a valid signature, and if that's a possibility, then it could happen to any Debian package, include one shipped with Tails.

What are the packages that you install this way? pdf-redact-tools, tesseract-ocr, and ffmpeg? Anything else?

Although there's no mainline debian package for it, it would be awesome to see peepdf (https://github.com/jesparza/peepdf) ported; It's already on Kali Linux's repos, which is Debian based, not sure if that makes it easier.

#6 Updated by sajolida 9 days ago

I may be wrong but if I'm thinking this through correctly, an adversary would have to seize the package maintainer's PGP private key to create a valid signature, and if that's a possibility, then it could happen to any Debian package, include one shipped with Tails.

I was seeing it differently. If you assume that you have a strong enough
adversary to possibly corrupt your airgaped Tails if it gets online
(ie. an adversary that has a way of rooting your Tails), then what
prevents this same adversary from rooting the computer from which the
packages are downloaded and put a malicious .deb on the USB drive that
you use to install additional packages using dpkg on the airgaped Tails?

Although there's no mainline debian package for it, it would be awesome to see peepdf (https://github.com/jesparza/peepdf) ported; It's already on Kali Linux's repos, which is Debian based, not sure if that makes it easier.

So, in order to prevent you from using Additional Software on your
airgaped Tails you would need pdf-redact-tools, tesseract-ocr, ffmpeg,
and peepdf. And until then, you would not gain much security or not for
all users. If my security analysis above makes sense, then it's the same
security risk whether you install 1 or 10 additional packages.

I could see Tails making an exception here and include the packages that
SecureDrop users need, because of these airgap requirements and because
SecureDrop users are very important to us. But I would need more
opinions from the team. @intrigeri: ^

Regarding peepdf, if there's already a .deb in Kali Linux, then it might
be a question of maintaining it in Debian. The best would be to have you
sponsor someone to maintain the package in Debian and maybe we can help
you find the right person. How would this sound?

#7 Updated by huertanix 9 days ago

sajolida wrote:

I was seeing it differently. If you assume that you have a strong enough
adversary to possibly corrupt your airgaped Tails if it gets online
(ie. an adversary that has a way of rooting your Tails), then what
prevents this same adversary from rooting the computer from which the
packages are downloaded and put a malicious .deb on the USB drive that
you use to install additional packages using dpkg on the airgaped Tails?

My understanding is that the use of the airgap is mainly there to keep any potential malicious code sent in via SecureDrop from escaping into the internet or newsroom network to exfiltrate data (such as a PGP private key) on the airgap. General attacks on Tails itself/an adversary getting root via the internet are a concern, but one that's mitigated by the containment of malicious files.

I could see Tails making an exception here and include the packages that
SecureDrop users need, because of these airgap requirements and because
SecureDrop users are very important to us. But I would need more
opinions from the team. @intrigeri: ^

That would be awesome! Would love to hear the rest of the team's thoughts.

Regarding peepdf, if there's already a .deb in Kali Linux, then it might
be a question of maintaining it in Debian. The best would be to have you
sponsor someone to maintain the package in Debian and maybe we can help
you find the right person. How would this sound?

Perhaps; I'm also wondering if it would be easy enough for the Kali package maintainer(s) to package it for mainline Debian to prevent having two different versions in Kali. I'll try to reach out to them.

#8 Updated by intrigeri 7 days ago

Hi,

huertanix wrote:

sajolida wrote:

I could see Tails making an exception here and include the packages that SecureDrop users need, because of these airgap requirements and because SecureDrop users are very important to us. But I would need more opinions from the team. intrigeri: ^

That would be awesome! Would love to hear the rest of the team's thoughts.

I'm open to this as well, as long as the list of such packages remains small enough and the security/UX impact for other Tails users is OK.

Now, my understanding is that adding these packages right now to Tails will not solve anything, given SecureDrop admins will still need to go through painful steps to install peepdf anyway. Correct?

Regarding peepdf, if there's already a .deb in Kali Linux, then it might be a question of maintaining it in Debian. The best would be to have you sponsor someone to maintain the package in Debian and maybe we can help you find the right person. How would this sound?

Perhaps; I'm also wondering if it would be easy enough for the Kali package maintainer(s) to package it for mainline Debian to prevent having two different versions in Kali. I'll try to reach out to them.

This sounds good to me. The Kali folks are generally happy to maintain their stuff directly in Debian so there's some hope :)

#9 Updated by sajolida 1 day ago

I'm open to this as well, as long as the list of such packages remains small enough and the security/UX impact for other Tails users is OK.

Ok, then let's do this. The packages that we removed in 3.14, 3.16, and
4.0 didn't cause a lot of noise, so I'm confident that it'll be easy to
remove these as well if we ever have to in the future.

Now, my understanding is that adding these packages right now to Tails will not solve anything, given SecureDrop admins will still need to go through painful steps to install peepdf anyway. Correct?

@huertanix: Indeed, that's an important point. It makes sense for us to
include everything that you need in Tails to prevent the painful (and
possibly dangerous) dpkg scripts, but as long as even 1 of your packages
is missing from Debian and Tails, it won't change anything to you if to
already have a few included in Tails.

So please clarify which list of packages that are already included in
Debian would make a significant difference for you and prevent the
painful dpkg scripts.

#10 Updated by sajolida 1 day ago

  • Status changed from New to Confirmed

#11 Updated by sajolida about 7 hours ago

My understanding is that the use of the airgap is mainly there to keep any potential malicious code sent in via SecureDrop from escaping into the internet or newsroom network to exfiltrate data (such as a PGP private key) on the airgap. General attacks on Tails itself/an adversary getting root via the internet are a concern, but one that's mitigated by the containment of malicious files.

I think that I finally wrapped my head around this. Let's see if I got it right. So the threat model is that you don't trust the airgapped machine because it opens all kind of unsafe documents. You don't want to ever connect it to the Internet because you're afraid of some unsafe document being able to root it and exfiltrate data, for example. But you're fine with trusting some other machine, for example, to upgrade the airgapped Tails or copy .deb files to it.

Then I think that it makes sense to provide some extension of the Additional Software mechanism. For example, Tails could automatically install any .deb file in a given directory. I don't know if it makes sense from an APT/DPKG point of view but we could have /live/persistence/TailsData_unlocked/deb and Additional Softwaren could forcefully install any Debian package in there. We wouldn't need an interface for that and a mention in the doc would suffice.

@intrigeri: Does this make sense? Then we could forget about installing more packages and pushing the missing ones into Debian.

Also available in: Atom PDF