Project

General

Profile

Bug #17398

Follow-up to "Stack one single SquashFS diff when upgrading"

Added by segfault about 2 months ago. Updated about 2 months ago.

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

0%

Feature Branch:
bugfix/17398-follow-up-to-15281
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

  • I did some minor improvements to bin/copy-iuks-to-rsync-server-and-verify.
  • Re: 4644ebf028592a53aa761527da29f21c5e2529c3
    There are multiple commands in that list which allow tails-install-iuk to execute arbitrary code as root, so why bother maintaining a list of commands instead of just allowing it to run all commands with sudo?
  • Re: cced26b68a2c1e59b7ff516bd80734b872706966
    The commit adds hopenpgp-tools to the list of packages required to release Tails, but I don't see any tool installed by that package being used.
  • Re: 7727622dbc81dcf46888d5999cff65e4d029c5d3
    I don't understand why you removed the comments explaining the purpose of the commands (IMO especially the explanation for `sudo true` is helpful). Even with the comments, the code should be copy-pastable - at least my shell ignores lines starting with #.

Related issues

Related to Tails - Feature #15281: Stack one single SquashFS diff when upgrading Resolved 04/13/2016
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

Associated revisions

Revision 0e8594a6 (diff)
Added by intrigeri about 2 months ago

Release process: drop package introduced by mistake (refs: #17398)

… by commit cced26b68a2c1e59b7ff516bd80734b872706966.

Revision 8414a51b (diff)
Added by intrigeri about 2 months ago

Upgrader dev doc: re-add explanations (refs: #17398)

I removed them in 7727622dbc81dcf46888d5999cff65e4d029c5d3
but segfault rightfully observed that they can be helpful.

History

#1 Updated by segfault about 2 months ago

  • Related to Feature #15281: Stack one single SquashFS diff when upgrading added

#2 Updated by segfault about 2 months ago

  • Feature Branch set to bugfix/17398-follow-up-to-15281

#3 Updated by intrigeri about 2 months ago

Hi,

segfault (2020-01-05):

  • I did some minor improvements to bin/copy-iuks-to-rsync-server-and-verify.

Thanks! As discussed on XMPP, I'm amending one of your (slightly incorrect) commit messages.

  • Re: 4644ebf028592a53aa761527da29f21c5e2529c3
    There are multiple commands in that list which allow tails-install-iuk to execute arbitrary code as root, so why bother maintaining a list of commands instead of just allowing it to run all commands with sudo?

It's true that a number of allowed commands listed there provide ways for an attacker who can convince tails-install-iuk to call them with arbitrary arguments to escalate to root. So that's a good question indeed. I've wondered too while working on #15281.

I'm often tempted myself to follow the line of reasoning "A ⇒ B and A is part of our attack surface already, so why bother about other forbidding X | X ⇒ B?".
But regularly, @groente reminds me that he's by default wary of this line of reasoning wrt. security, and I'm inclined to trust his experience & skillset in this area (that are vastly greater than mine).

I don't know how he would explain it but from my standpoint, I think this question often boils down to whether it's easier to:

  • (1) Prove that there's no case in which the attacker can do X but not A. And ensure this remains the case.
  • (2) Set up & maintain the possibly useless mitigation measure.

In the case at hand, (2) was set up already and we've updated it 3 times in the last 5 years, so its maintenance cost seems pretty low to me.
So in doubt, I'm tempted to leave things as-is.
What do you think?

  • Re: cced26b68a2c1e59b7ff516bd80734b872706966
    The commit adds hopenpgp-tools to the list of packages required to release Tails, but I don't see any tool installed by that package being used.

You have eagle eyes! Indeed, that's cruft leftover from other attempts to generate tails-signing-minimal.key in a deterministic way (better audit track record, less churn in Git history). Removed.

  • Re: 7727622dbc81dcf46888d5999cff65e4d029c5d3
    I don't understand why you removed the comments explaining the purpose of the commands (IMO especially the explanation for `sudo true` is helpful). Even with the comments, the code should be copy-pastable - at least my shell ignores lines starting with #.

I did this because this was not copy'n'paste-able in the shell I'm using (Zsh). I don't know if other release managers have the same problem.

But you're right, these comments were useful, so I've re-added them.

My two commits were trivial changes that you requested so I'm going to merge the branch into stable.
But I'm leaving this ticket open so we can discuss the sudo config.

#4 Updated by intrigeri about 2 months ago

  • Status changed from Confirmed to In Progress

#5 Updated by intrigeri about 2 months ago

#6 Updated by segfault about 2 months ago

  • Status changed from In Progress to Resolved

intrigeri wrote:

  • Re: 4644ebf028592a53aa761527da29f21c5e2529c3
    There are multiple commands in that list which allow tails-install-iuk to execute arbitrary code as root, so why bother maintaining a list of commands instead of just allowing it to run all commands with sudo?

It's true that a number of allowed commands listed there provide ways for an attacker who can convince tails-install-iuk to call them with arbitrary arguments to escalate to root. So that's a good question indeed. I've wondered too while working on #15281.

I'm often tempted myself to follow the line of reasoning "A ⇒ B and A is part of our attack surface already, so why bother about other forbidding X | X ⇒ B?".
But regularly, @groente reminds me that he's by default wary of this line of reasoning wrt. security, and I'm inclined to trust his experience & skillset in this area (that are vastly greater than mine).

I don't know how he would explain it but from my standpoint, I think this question often boils down to whether it's easier to:

  • (1) Prove that there's no case in which the attacker can do X but not A. And ensure this remains the case.
  • (2) Set up & maintain the possibly useless mitigation measure.

In the case at hand, (2) was set up already and we've updated it 3 times in the last 5 years, so its maintenance cost seems pretty low to me.
So in doubt, I'm tempted to leave things as-is.
What do you think?

I can't think of a case where an attacker could do X (execute commands with sudo that are not in the list) but not A (execute commands with sudo from the list). Anyway, the maintenance cost seems so low that it's not worth spending more time on this. So lets just keep the list.

  • Re: 7727622dbc81dcf46888d5999cff65e4d029c5d3
    I don't understand why you removed the comments explaining the purpose of the commands (IMO especially the explanation for `sudo true` is helpful). Even with the comments, the code should be copy-pastable - at least my shell ignores lines starting with #.

I did this because this was not copy'n'paste-able in the shell I'm using (Zsh).

Interesting. I also use zsh and I have no problem copy-pasting the commands with the comment lines.

#7 Updated by intrigeri about 2 months ago

I did this because this was not copy'n'paste-able in the shell I'm using (Zsh).

Interesting. I also use zsh and I have no problem copy-pasting the commands with the comment lines.

This picked my curiosity! setopt interactive_comments fixes this for me.

#8 Updated by segfault about 2 months ago

intrigeri wrote:

I did this because this was not copy'n'paste-able in the shell I'm using (Zsh).

Interesting. I also use zsh and I have no problem copy-pasting the commands with the comment lines.

This picked my curiosity! setopt interactive_comments fixes this for me.

Ah :)

Also available in: Atom PDF