Feature #14880

Set resource limits

Added by cypherpunks 2017-10-26 08:05:50 . Updated 2020-02-28 08:00:21 .

Status:
Confirmed
Priority:
Low
Assignee:
Category:
Target version:
Start date:
2017-10-26
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

Currently, Tails does no resource limitation, even though it is supported by PAM through the /etc/security/limits.conf file. The rlimits primarily reduce the risk of DoS through, say, fork bombs, and it can reduce vulnerabilities. Some examples:

  • RLIMIT_STACK can mitigate various ASLR-exhaustion attacks.
  • RLIMIT_AS can mitigate some types of integer overflows (such as the RCE libotr had, or the large number of X11 extension vulnerabilities).
  • RLIMIT_NICE can make some side-channel attacks a bit harder.
  • RLIMIT_CORE can allow debugging crashes that were potentially caused by exploits.
  • RLIMIT_NPROC can mitigate many of the easiest forms of DoSes, as well as make side-channel attacks harder.
  • RLIMIT_CPU can make side-channel attacks and attacks like rowhammer harder, when used wisely.

Resource limits can be applied to users or groups, though the prlimit64() syscall can be used to set it for processes which are already running. I suggest limiting AS for all processes but the browser (as it is the most likely to have a legitimate need to eat up lots of memory) and similar bloated beasts, the number of processes for the amnesia user, and the stack size and niceness for all processes (setting it to even 8 MiB would be enough). The core limit should be lifted or made very liberal, and coredumps configured to log to journald. I assume coredumps logged there are not readable by unprivileged users (to prevent, say, sending SIGSEGV to a victim process in order to read potentially sensitive memory contents). Reducing other limits can be done as deemed safe. Individual sensitive users can be restricted more, such as the debian-tor user.

Please consider taking advantage of this simple but useful PAM feature.

Subtasks

History

#1 Updated by mercedes508 2017-11-27 15:10:59

  • Assignee set to emmapeel

#2 Updated by emmapeel 2018-01-12 12:22:42

  • Assignee changed from emmapeel to intrigeri

Ey intri can you please have a look at this idea?

#3 Updated by intrigeri 2018-01-12 13:58:59

  • Subject changed from Set resource limits using PAM to Set resource limits
  • Status changed from New to Confirmed
  • Assignee deleted (intrigeri)
  • Priority changed from Normal to Low
  • Type of work changed from Code to Research

I’m not fully convinced the cost/benefit ratio is interesting but if someone wants to research this seriously, find which specific limits would efficiently prevent attacks without harming UX, and propose a way to implement them, then I’ll be happy to review it. I’d really like the implementation to be simple, easy to audit & maintain, and backed by good explanations. In many cases it would probably make sense to implement such things directly in upstream software or in the Debian packaging, instead of adding to the Tails delta we have to maintain.

Regarding how exactly to apply the limits, for anything that’s run by systemd I recommend looking at the Limit*= directives, e.g. on my system I see a number of units that set LimitNPROC= to a low value.

#4 Updated by cypherpunks 2018-06-04 05:32:35

intrigeri wrote:
> I’m not fully convinced the cost/benefit ratio is interesting but if someone wants to research this seriously, find which specific limits would efficiently prevent attacks without harming UX, and propose a way to implement them, then I’ll be happy to review it. I’d really like the implementation to be simple, easy to audit & maintain, and backed by good explanations. In many cases it would probably make sense to implement such things directly in upstream software or in the Debian packaging, instead of adding to the Tails delta we have to maintain.

What is the cost, exactly? For any sane limits, there should be no UX issues at all. For example limiting the stack to 8 MiB should not interfere with any programs. Limiting the AS to under 2 GiB for most programs would mitigate real-life vulnerabilities (like that one libotr integer overflow bug from some time ago). Limiting niceness would not affect any existing programs and would make side-channel attacks harder, etc.

I am also curious to know how this would increase the Tails delta. Obviously the changes would be exclusively Tails-specific, so making them default in upstream would be silly. Debian provides us with configuration options to use for this very reason. It’s not like we have to provide a program that applies all of these manually with prlimit64() or something. All it requires is editing /etc/pam.d/security or whatever systemd uses if it is systemd-specific.

#5 Updated by intrigeri 2020-02-28 08:00:21

It was reported to us that some websites, when visited in Tor Browser, can make the full Tails system unresponsive. I guess that’s due to resources exhaustion.

In Tails 5.0, most likely each app will be run within its own systemd scope, which may make it easier to set per-app resource limits, so when the aforementioned problem happens:

  • the user can restart Tor Browser instead of restarting Tails
  • the user does not lose work they’ve been doing outside of Tor Browser